From marcos_antonio_ps at hotmail.com Tue Mar 1 03:27:37 2011 From: marcos_antonio_ps at hotmail.com (Marcos Antonio) Date: Tue, 1 Mar 2011 14:27:37 +0300 Subject: Trying the new SAM types and collection methods Message-ID: Hello, everybody! I've been trying the lambda prototype for a while and it's being a good experience. I used this to clone (which creates the directory "C:\lambda\langtools" in my machine): hg clone http://hg.openjdk.java.net/lambda/lambda/langtools this to compile the langtools: ant -Dboot.java.home="C:\Java\jdk1.6.0_22" -Dtarget.java.home="C:\Java\jdk1.7.0" -Dimport.jdk="C:\Java\jdk1.7.0" build-all-tools and these options to run my application: -XX:+UnlockExperimentalVMOptions -XX:+EnableMethodHandles -XX:+EnableInvokeDynamic Now I saw that the URL for the new things that I want to try is: http://hg.openjdk.java.net/lambda/collections/jdk (I suppose) This is where my doubts start. When I click with the right mouse button on the directory "C:\lambda\langtools" the TortoiseHg presents me some options like "Synchronize" and "Update". I don't know if I have to pull the changes from the above URL in this directory (langtools) or if I have to create another directory (for example, "C:\lambda\jdk") and how to compile the files after that. I haven't tried anything of these yet because I was afraid of messing my langtools installation. So I would like to have your help telling me how I should proceed to update and compile these new features (SAM types and collection methods). Thank you very much. Marcos From maurizio.cimadamore at oracle.com Tue Mar 1 03:54:33 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 1 Mar 2011 03:54:33 -0800 (PST) Subject: Trying the new SAM types and collection methods In-Reply-To: References: Message-ID: <4D6CDE79.4090809@oracle.com> On 01/03/11 11:27, Marcos Antonio wrote: > Hello, everybody! > > I've been trying the lambda prototype for a while and it's being a good experience. > > I used this to clone (which creates the directory "C:\lambda\langtools" in my machine): > hg clone http://hg.openjdk.java.net/lambda/lambda/langtools > > this to compile the langtools: > ant -Dboot.java.home="C:\Java\jdk1.6.0_22" -Dtarget.java.home="C:\Java\jdk1.7.0" -Dimport.jdk="C:\Java\jdk1.7.0" build-all-tools > > and these options to run my application: > -XX:+UnlockExperimentalVMOptions > -XX:+EnableMethodHandles > -XX:+EnableInvokeDynamic > > Now I saw that the URL for the new things that I want to try is: > > http://hg.openjdk.java.net/lambda/collections/jdk (I suppose) > > This is where my doubts start. When I click with the right mouse button on the directory "C:\lambda\langtools" > the TortoiseHg presents me some options like "Synchronize" and "Update". I don't know if I have to pull the changes > from the above URL in this directory (langtools) or if I have to create another directory (for example, "C:\lambda\jdk") > and how to compile the files after that. I haven't tried anything of these yet because I was afraid of messing my > langtools installation. The way to do it is to: *) clone the entire collections repository (http://hg.openjdk.java.net/lambda/collections) *) remove the langtools folder from the newly created repo (from step above) *) clone the lambda main langtools repo (http://hg.openjdk.java.net/lambda/lambda/langtools) *) build the jdk Maurizio > > So I would like to have your help telling me how I should proceed to update and compile these new features (SAM types > and collection methods). > > Thank you very much. > > Marcos > From marcos_antonio_ps at hotmail.com Tue Mar 1 06:04:38 2011 From: marcos_antonio_ps at hotmail.com (Marcos Antonio) Date: Tue, 1 Mar 2011 17:04:38 +0300 Subject: Trying the new SAM types and collection methods In-Reply-To: <4D6CDE79.4090809@oracle.com> References: , <4D6CDE79.4090809@oracle.com> Message-ID: Thank you. Marcos > Date: Tue, 1 Mar 2011 03:54:33 -0800 > From: maurizio.cimadamore at oracle.com > To: marcos_antonio_ps at hotmail.com > CC: lambda-dev at openjdk.java.net > Subject: Re: Trying the new SAM types and collection methods > > On 01/03/11 11:27, Marcos Antonio wrote: > > Hello, everybody! > > > > I've been trying the lambda prototype for a while and it's being a good experience. > > > > I used this to clone (which creates the directory "C:\lambda\langtools" in my machine): > > hg clone http://hg.openjdk.java.net/lambda/lambda/langtools > > > > this to compile the langtools: > > ant -Dboot.java.home="C:\Java\jdk1.6.0_22" -Dtarget.java.home="C:\Java\jdk1.7.0" -Dimport.jdk="C:\Java\jdk1.7.0" build-all-tools > > > > and these options to run my application: > > -XX:+UnlockExperimentalVMOptions > > -XX:+EnableMethodHandles > > -XX:+EnableInvokeDynamic > > > > Now I saw that the URL for the new things that I want to try is: > > > > http://hg.openjdk.java.net/lambda/collections/jdk (I suppose) > > > > This is where my doubts start. When I click with the right mouse button on the directory "C:\lambda\langtools" > > the TortoiseHg presents me some options like "Synchronize" and "Update". I don't know if I have to pull the changes > > from the above URL in this directory (langtools) or if I have to create another directory (for example, "C:\lambda\jdk") > > and how to compile the files after that. I haven't tried anything of these yet because I was afraid of messing my > > langtools installation. > The way to do it is to: > > *) clone the entire collections repository > (http://hg.openjdk.java.net/lambda/collections) > *) remove the langtools folder from the newly created repo (from step above) > *) clone the lambda main langtools repo > (http://hg.openjdk.java.net/lambda/lambda/langtools) > *) build the jdk > > Maurizio > > > > So I would like to have your help telling me how I should proceed to update and compile these new features (SAM types > > and collection methods). > > > > Thank you very much. > > > > Marcos > > > From brian.goetz at oracle.com Tue Mar 1 08:12:13 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 1 Mar 2011 08:12:13 -0800 Subject: Trying the new SAM types and collection methods In-Reply-To: References: Message-ID: <341B4478-7DA2-4678-A8A8-B98FBE75F0E6@oracle.com> The VM support for extension methods is not there yet. We're working on some tools that will do the appropriate weaving at build time or load time to simulate this, stay tuned. On Mar 1, 2011, at 3:27 AM, Marcos Antonio wrote: > > Hello, everybody! > > I've been trying the lambda prototype for a while and it's being a good experience. > > I used this to clone (which creates the directory "C:\lambda\langtools" in my machine): > hg clone http://hg.openjdk.java.net/lambda/lambda/langtools > > this to compile the langtools: > ant -Dboot.java.home="C:\Java\jdk1.6.0_22" -Dtarget.java.home="C:\Java\jdk1.7.0" -Dimport.jdk="C:\Java\jdk1.7.0" build-all-tools > > and these options to run my application: > -XX:+UnlockExperimentalVMOptions > -XX:+EnableMethodHandles > -XX:+EnableInvokeDynamic > > Now I saw that the URL for the new things that I want to try is: > > http://hg.openjdk.java.net/lambda/collections/jdk (I suppose) > > This is where my doubts start. When I click with the right mouse button on the directory "C:\lambda\langtools" > the TortoiseHg presents me some options like "Synchronize" and "Update". I don't know if I have to pull the changes > from the above URL in this directory (langtools) or if I have to create another directory (for example, "C:\lambda\jdk") > and how to compile the files after that. I haven't tried anything of these yet because I was afraid of messing my > langtools installation. > > So I would like to have your help telling me how I should proceed to update and compile these new features (SAM types > and collection methods). > > Thank you very much. > > Marcos > From neal at gafter.com Tue Mar 1 09:35:38 2011 From: neal at gafter.com (Neal Gafter) Date: Tue, 1 Mar 2011 09:35:38 -0800 Subject: The lambda conversion and a lambda body that doesn't complete. Message-ID: Dear Lambdans- Given *interface F { int invoke(); }* I would like to be able to write *F x = #{ throw new Exception(); }; * (Modulo syntax - whatever the current syntax is) But according to the current draft specification that's not allowed (the lambda as written can only be converted to a SAM with a void return type). I think that whether or not the lambda's body can complete normally should be taken into account in the lambda conversion to make this legal. As a point of information, the behavior I prefer is the behavior of Scala, BGGA, and C# (among others). This is also consistent with the way method implementations work: *int f() { throw new Exception(); }* In the unfortunate case that you need use cases for this, draft specification language, or suggestions for a straightforward implementation, I can provide those. Cheers, Neal From maurizio.cimadamore at oracle.com Tue Mar 1 09:49:11 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 01 Mar 2011 17:49:11 +0000 Subject: hg: lambda/lambda: 32 new changesets Message-ID: <20110301174912.5215747B80@hg.openjdk.java.net> Changeset: 5c4df7e99277 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/5c4df7e99277 Added tag jdk7-b124 for changeset 024a6755895b ! .hgtags Changeset: b566d4909056 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/b566d4909056 Added tag jdk7-b125 for changeset 5c4df7e99277 ! .hgtags Changeset: bd70f76b0309 Author: cl Date: 2011-01-20 15:51 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/bd70f76b0309 Added tag jdk7-b126 for changeset b566d4909056 ! .hgtags Changeset: 6e0f4d6099bb Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/6e0f4d6099bb Added tag jdk7-b127 for changeset bd70f76b0309 ! .hgtags Changeset: f722c246ce71 Author: mchung Date: 2011-01-20 22:16 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/f722c246ce71 7013739: jdk_rmi target is missing in the top repo's test/Makefile Reviewed-by: ohair, igor ! test/Makefile Changeset: 65e6601596e2 Author: lana Date: 2011-01-24 13:21 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/65e6601596e2 Merge Changeset: 61f181d43d9a Author: lana Date: 2011-01-28 10:00 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/61f181d43d9a Merge Changeset: 6db0e6f221bd Author: ohair Date: 2011-01-05 17:24 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/6db0e6f221bd 7009969: Remove SKIP_OPENJDK_BUILD from top Makefile Reviewed-by: robilad ! Makefile ! make/Defs-internal.gmk Changeset: 49c463695059 Author: ohair Date: 2011-01-10 10:00 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/49c463695059 Merge Changeset: 6d9bbcc0a8cb Author: ohair Date: 2011-01-13 17:55 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/6d9bbcc0a8cb Merge Changeset: 24900a58ab9f Author: ohair Date: 2011-01-14 14:04 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/24900a58ab9f 6950375: Remove msvcrt.dll from the Windows JRE bundles Reviewed-by: prr ! Makefile ! README-builds.html Changeset: 3a9f19cbf7f1 Author: ohair Date: 2011-01-26 16:05 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/3a9f19cbf7f1 Merge Changeset: a7a4f6db294d Author: ohair Date: 2011-01-27 18:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/a7a4f6db294d Merge Changeset: 57d702105b23 Author: ohair Date: 2011-02-02 09:38 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/57d702105b23 Merge Changeset: 904d7c7c44d9 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/904d7c7c44d9 Added tag jdk7-b128 for changeset 57d702105b23 ! .hgtags Changeset: ce02c0d73d6a Author: ohair Date: 2011-02-03 15:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/ce02c0d73d6a 7014634: By default, only build the product bits with a closed jdk build (like openjdk does) Reviewed-by: katleman, cl, igor, trims ! make/Defs-internal.gmk Changeset: e2a214ec8ebc Author: ohair Date: 2011-02-04 07:47 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/e2a214ec8ebc Merge Changeset: a6b015b59fbc Author: ohair Date: 2011-02-08 16:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/a6b015b59fbc 7016976: Documentation for required ant version on JDK7 builds on Solaris 10 and Solaris 11 Reviewed-by: rinaldo ! README-builds.html Changeset: cc58c11af154 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/cc58c11af154 Added tag jdk7-b129 for changeset a6b015b59fbc ! .hgtags Changeset: 995077c73fbb Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/995077c73fbb Added tag jdk7-b130 for changeset cc58c11af154 ! .hgtags Changeset: 0fd0aeb592cb Author: jqzuo Date: 2010-12-09 10:58 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/rev/0fd0aeb592cb Merge Changeset: 20955959b7b7 Author: jqzuo Date: 2010-12-22 15:55 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/rev/20955959b7b7 Merge Changeset: 08fe18caf411 Author: jqzuo Date: 2011-01-10 13:45 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/rev/08fe18caf411 Merge Changeset: aee1b0183364 Author: jqzuo Date: 2011-01-24 17:14 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/rev/aee1b0183364 Merge Changeset: 12764a5a3aec Author: jqzuo Date: 2011-02-01 15:03 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/rev/12764a5a3aec Merge Changeset: df3abd560cbd Author: jqzuo Date: 2011-02-09 16:05 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/rev/df3abd560cbd Merge Changeset: e2370dfcc721 Author: paulk Date: 2011-02-14 14:29 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/rev/e2370dfcc721 7019371: JDK7 is not building UPX. IFTW wrappers are not compressed. Reviewed-by: billyh, jqzuo ! make/deploy-rules.gmk Changeset: 5466f13d19be Author: jqzuo Date: 2011-02-21 14:18 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/rev/5466f13d19be Merge Changeset: da55264ff2fb Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/da55264ff2fb 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 5d86d951426a Author: cl Date: 2011-02-23 15:48 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/5d86d951426a Merge Changeset: 0f62a65fb666 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/rev/0f62a65fb666 Added tag jdk7-b131 for changeset 5d86d951426a ! .hgtags Changeset: 4a6a3619c7a3 Author: mcimadamore Date: 2011-03-01 17:45 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/rev/4a6a3619c7a3 merge with jdk7-b131 From maurizio.cimadamore at oracle.com Tue Mar 1 09:49:41 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 01 Mar 2011 17:49:41 +0000 Subject: hg: lambda/lambda/corba: 17 new changesets Message-ID: <20110301174953.0845047B81@hg.openjdk.java.net> Changeset: 1ce58c72b789 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/1ce58c72b789 Added tag jdk7-b124 for changeset f90b3e014e83 ! .hgtags Changeset: d7532bcd3742 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/d7532bcd3742 Added tag jdk7-b125 for changeset 1ce58c72b789 ! .hgtags Changeset: 64775e83f4df Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/64775e83f4df Added tag jdk7-b126 for changeset d7532bcd3742 ! .hgtags Changeset: 9baa8f94a11d Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/9baa8f94a11d Added tag jdk7-b127 for changeset 64775e83f4df ! .hgtags Changeset: 3ff9acc7cc06 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/3ff9acc7cc06 Added tag jdk7-b128 for changeset 9baa8f94a11d ! .hgtags Changeset: 6a3903e5b6cc Author: ohair Date: 2011-02-03 15:05 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/6a3903e5b6cc 6944304: Potential rebranding issues in the openjdk7/corba sources Reviewed-by: alanb, mchung, darcy ! src/share/classes/com/sun/corba/se/spi/logging/data/Activation.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/IOR.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Interceptors.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Naming.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/OMG.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/ORBUtil.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/POA.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Util.mc Changeset: 66fa0fcc7792 Author: ohair Date: 2011-02-04 07:47 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/66fa0fcc7792 Merge Changeset: 4cdf9b86f550 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/4cdf9b86f550 Added tag jdk7-b129 for changeset 66fa0fcc7792 ! .hgtags Changeset: 30ecf5c90a30 Author: mfang Date: 2011-02-10 11:07 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/30ecf5c90a30 7014477: pt_BR corba resource bundle is missing in jdk7 build Reviewed-by: ohair ! make/common/Defs.gmk Changeset: c08dff674e53 Author: mfang Date: 2011-02-10 14:25 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/c08dff674e53 7017734: jdk7 message drop 1 translation integration Reviewed-by: ogino, yhuang ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties Changeset: e0f0b358cd2c Author: mfang Date: 2011-02-11 22:50 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/e0f0b358cd2c Merge Changeset: 563a8f8b5be3 Author: mfang Date: 2011-02-11 23:35 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/563a8f8b5be3 Merge Changeset: 49a96611c870 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/49a96611c870 Added tag jdk7-b130 for changeset 563a8f8b5be3 ! .hgtags Changeset: a9335b646c1c Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/a9335b646c1c 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 9d6dd2cdfcb9 Author: cl Date: 2011-02-23 15:48 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/9d6dd2cdfcb9 Merge Changeset: 1b1e75e8f476 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/1b1e75e8f476 Added tag jdk7-b131 for changeset 9d6dd2cdfcb9 ! .hgtags Changeset: 8ee094220abc Author: mcimadamore Date: 2011-03-01 15:03 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/8ee094220abc merge with jdk7-b131 From maurizio.cimadamore at oracle.com Tue Mar 1 09:50:09 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 01 Mar 2011 17:50:09 +0000 Subject: hg: lambda/lambda/jaxws: 16 new changesets Message-ID: <20110301175009.4EF2847B82@hg.openjdk.java.net> Changeset: d72eea121c3b Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/d72eea121c3b Added tag jdk7-b124 for changeset 86f60e5b3975 ! .hgtags Changeset: e8fc02b4c889 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/e8fc02b4c889 Added tag jdk7-b125 for changeset d72eea121c3b ! .hgtags Changeset: aca101db2361 Author: ohair Date: 2010-12-16 13:14 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/aca101db2361 7006853: Integrate JAX-WS 2.2.2 RI into JDK 7 Reviewed-by: ramap ! jaxws.properties Changeset: 8ac759987b08 Author: lana Date: 2010-12-22 22:57 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/8ac759987b08 Merge Changeset: 466e89f7e5be Author: lana Date: 2011-01-04 16:37 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/466e89f7e5be Merge ! jaxws.properties Changeset: dba69d6345d9 Author: lana Date: 2011-01-13 14:55 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/dba69d6345d9 Merge Changeset: 6d772c5119d5 Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/6d772c5119d5 Merge Changeset: ef19f173578c Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/ef19f173578c Added tag jdk7-b126 for changeset 6d772c5119d5 ! .hgtags Changeset: 88d74afc5593 Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/88d74afc5593 Added tag jdk7-b127 for changeset ef19f173578c ! .hgtags Changeset: 0f7b39ad9024 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/0f7b39ad9024 Added tag jdk7-b128 for changeset 88d74afc5593 ! .hgtags Changeset: ba1fac1c2083 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/ba1fac1c2083 Added tag jdk7-b129 for changeset 0f7b39ad9024 ! .hgtags Changeset: a8ffd75ad5df Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/a8ffd75ad5df Added tag jdk7-b130 for changeset ba1fac1c2083 ! .hgtags Changeset: 9e3904866cab Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/9e3904866cab 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 438abc0356cd Author: cl Date: 2011-02-23 15:49 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/438abc0356cd Merge Changeset: 0e57c3272d37 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/0e57c3272d37 Added tag jdk7-b131 for changeset 438abc0356cd ! .hgtags Changeset: 3344673321b6 Author: mcimadamore Date: 2011-03-01 15:04 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/3344673321b6 merge with jdk7-b131 From maurizio.cimadamore at oracle.com Tue Mar 1 09:50:29 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 01 Mar 2011 17:50:29 +0000 Subject: hg: lambda/lambda/jaxp: 16 new changesets Message-ID: <20110301175029.5253247B83@hg.openjdk.java.net> Changeset: 6c9bdee0cc3a Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/6c9bdee0cc3a Added tag jdk7-b124 for changeset 57ed1f3bec72 ! .hgtags Changeset: 116b935148bc Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/116b935148bc Added tag jdk7-b125 for changeset 6c9bdee0cc3a ! .hgtags Changeset: 63190d0ca619 Author: ohair Date: 2010-12-16 13:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/63190d0ca619 7007257: jaxp 1.4.5 jdk7 1st integration Reviewed-by: joehw ! jaxp.properties Changeset: ce7b69a2d927 Author: lana Date: 2010-12-22 22:57 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/ce7b69a2d927 Merge Changeset: 3a829f5ba9d2 Author: lana Date: 2011-01-04 16:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/3a829f5ba9d2 Merge Changeset: 64c84c62ec2a Author: lana Date: 2011-01-13 14:55 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/64c84c62ec2a Merge Changeset: 2fde639439c1 Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/2fde639439c1 Merge Changeset: c532d6dbc8d1 Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/c532d6dbc8d1 Added tag jdk7-b126 for changeset 2fde639439c1 ! .hgtags Changeset: a42c6132c746 Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/a42c6132c746 Added tag jdk7-b127 for changeset c532d6dbc8d1 ! .hgtags Changeset: f5b60c5a310f Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/f5b60c5a310f Added tag jdk7-b128 for changeset a42c6132c746 ! .hgtags Changeset: ab107c1bc4b9 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/ab107c1bc4b9 Added tag jdk7-b129 for changeset f5b60c5a310f ! .hgtags Changeset: f2ad604323c0 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/f2ad604323c0 Added tag jdk7-b130 for changeset ab107c1bc4b9 ! .hgtags Changeset: a57220f22751 Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/a57220f22751 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: eab6f27131e4 Author: cl Date: 2011-02-23 15:48 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/eab6f27131e4 Merge Changeset: abe04c59a556 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/abe04c59a556 Added tag jdk7-b131 for changeset eab6f27131e4 ! .hgtags Changeset: 01bddf4e7b40 Author: mcimadamore Date: 2011-03-01 15:04 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/01bddf4e7b40 merge with jdk7-b131 From maurizio.cimadamore at oracle.com Tue Mar 1 09:51:08 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 01 Mar 2011 17:51:08 +0000 Subject: hg: lambda/lambda/hotspot: 148 new changesets Message-ID: <20110301175528.4C0AB47B84@hg.openjdk.java.net> Changeset: 09d92cbb793b Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/09d92cbb793b Added tag jdk7-b124 for changeset 0a8e0d4345b3 ! .hgtags Changeset: f6a707dbaddb Author: trims Date: 2011-01-07 19:09 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f6a707dbaddb Added tag hs20-b05 for changeset 0a8e0d4345b3 ! .hgtags Changeset: 9fc3ffb1e0b1 Author: trims Date: 2011-01-07 22:42 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9fc3ffb1e0b1 7011125: Bump the HS20 build number to 06 Summary: Update the HS20 build number to 06 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 6da3527317ff Author: kevinw Date: 2010-12-17 12:14 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6da3527317ff 7003487: clhsdbproc stacktrace fails on x64 Reviewed-by: phh ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java Changeset: 02895c6a2f82 Author: bobv Date: 2010-12-20 14:30 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/02895c6a2f82 7007769: VM crashes with SIGBUS writing PerfData if tmp space is full Summary: Fill perfdata file with zeros to verify available disk space Reviewed-by: coleenp, kamg ! src/os/linux/vm/perfMemory_linux.cpp Changeset: e58d06a8037e Author: dholmes Date: 2010-12-21 23:39 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e58d06a8037e 7008444: Remove unnecessary include of stdint.h in java_md.c Summary: Remove unnecessary include of stdint.h in java_md.c Reviewed-by: brutisso, kvn ! src/os/posix/launcher/java_md.c Changeset: 1e637defdda6 Author: zgu Date: 2010-12-22 11:24 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1e637defdda6 6961186: Better VM handling of unexpected exceptions from application native code Summary: Trap uncaught C++ exception on Windows and Solaris and generate hs_err report. Reviewed-by: coleenp, bobv, dholmes ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: c19157304e08 Author: zgu Date: 2010-12-22 11:52 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c19157304e08 Merge ! src/os/windows/vm/os_windows.cpp Changeset: 3da13a976363 Author: coleenp Date: 2010-12-22 12:24 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3da13a976363 Merge ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java Changeset: 07c62ff47437 Author: coleenp Date: 2010-12-22 16:52 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/07c62ff47437 Merge Changeset: d6cd0d55d0b5 Author: dcubed Date: 2010-12-23 07:58 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d6cd0d55d0b5 6987812: 2/3 SAJDI: "gHotSpotVMTypes was not initialized properly in the remote process" Summary: Change ExportDirectoryTableImpl to return the 'Export RVA' field without modification. Read 'Base Of Data' field in optional header when PE32 format COFF file is read. Refine search for dbgeng.dll and dbghelp.dll. Other cleanups. Reviewed-by: swamyv, poonam ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/coff/COFFFileParser.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/coff/DumpExports.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/coff/TestParser.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java Changeset: e0c969b97f66 Author: zgu Date: 2010-12-27 09:30 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e0c969b97f66 6975480: VS2010 says _STATIC_CPPLIB is deprecated, may need to change this usage Summary: Disabled the warning message during compiling. Reviewed-by: coleenp, dholmes ! make/windows/makefiles/compile.make Changeset: dbf8dcf069d1 Author: zgu Date: 2010-12-27 09:56 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/dbf8dcf069d1 Merge ! make/windows/makefiles/compile.make Changeset: 06e4b9c9db76 Author: coleenp Date: 2010-12-28 09:54 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/06e4b9c9db76 Merge Changeset: 7737fa7ec2b5 Author: twisti Date: 2010-12-14 12:44 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7737fa7ec2b5 7006044: materialize cheap non-oop pointers on 64-bit SPARC Summary: After 6961690 we load non-oop pointers for the constant table which could easily be materialized in a few instructions. Reviewed-by: never, kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad Changeset: 781072b12368 Author: never Date: 2010-12-14 23:17 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/781072b12368 6765546: Wrong sscanf used to parse CompilerOracle command >= 32 characters could lead to crash Reviewed-by: kvn, iveresov ! src/share/vm/compiler/compilerOracle.cpp Changeset: 4042471b7419 Author: iveresov Date: 2010-12-16 01:46 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4042471b7419 Merge Changeset: cccd1b172b85 Author: never Date: 2010-12-16 12:47 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/cccd1b172b85 6839888: Array overrun in vm adlc Reviewed-by: kvn, iveresov ! src/share/vm/adlc/dict2.cpp Changeset: c04052fd6ae1 Author: kvn Date: 2010-12-16 14:15 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c04052fd6ae1 7006505: Use kstat info to identify SPARC processor Summary: read Solaris kstat data to get more precise CPU information Reviewed-by: iveresov, never, twisti, dholmes ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/vm.make ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/memory/universe.cpp Changeset: 7223744c2784 Author: never Date: 2010-12-17 15:55 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7223744c2784 6579789: Internal error "c1_LinearScan.cpp:1429 Error: assert(false,"")" in debuggee with fastdebug VM Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp + test/compiler/6579789/Test6579789.java Changeset: 52d615436cef Author: never Date: 2010-12-18 06:40 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/52d615436cef Merge Changeset: 7d9caaedafce Author: twisti Date: 2010-12-18 01:15 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7d9caaedafce 6990933: assert(sender_cb) failed: sanity in frame::sender_for_interpreter_frame Reviewed-by: never ! src/share/vm/code/nmethod.cpp Changeset: 1fb0500f550e Author: twisti Date: 2010-12-18 08:38 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1fb0500f550e Merge Changeset: ef3c5db0b3ae Author: twisti Date: 2010-12-21 04:37 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ef3c5db0b3ae 7008165: Garbage in ClassFormatError message Summary: When bootstrap_method_ref in BootstrapMethods attribute points to a wrong CP entry (non-MethodHandle), JVM throws ClassFormatError with a message, where method index and class file name is garbage. Reviewed-by: iveresov ! src/share/vm/classfile/classFileParser.cpp Changeset: a21ff35351ec Author: kvn Date: 2010-12-21 13:56 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a21ff35351ec 7003130: assert(iterations start) failed: need enough space to divide up Summary: Codebuffer can overflow on test with large number of calls Reviewed-by: dholmes, collins ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp Changeset: 4537d449ba57 Author: bobv Date: 2011-01-07 15:57 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4537d449ba57 Merge Changeset: b1a2afa37ec4 Author: phh Date: 2011-01-07 10:42 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b1a2afa37ec4 7003271: Hotspot should track cumulative Java heap bytes allocated on a per-thread basis Summary: Track allocated bytes in Thread's, update on TLAB retirement and direct allocation in Eden and tenured, add JNI methods for ThreadMXBean. Reviewed-by: coleenp, kvn, dholmes, ysr ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/thread_solaris.inline.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp Changeset: 55d7d18ccff9 Author: dcubed Date: 2011-01-07 13:59 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/55d7d18ccff9 Merge Changeset: 84f36150fcc3 Author: dcubed Date: 2011-01-07 15:54 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/84f36150fcc3 Merge ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/os/solaris/vm/os_solaris.cpp Changeset: e24ab3fa6aaf Author: trims Date: 2011-01-07 22:56 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e24ab3fa6aaf Merge ! make/jprt.properties Changeset: 4c851c931d00 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4c851c931d00 Added tag jdk7-b125 for changeset e24ab3fa6aaf ! .hgtags Changeset: 102466e70deb Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/102466e70deb Added tag jdk7-b126 for changeset 4c851c931d00 ! .hgtags Changeset: 907c1aed0f8c Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/907c1aed0f8c Added tag jdk7-b127 for changeset 102466e70deb ! .hgtags Changeset: e4f8c88cf6f0 Author: trims Date: 2011-01-13 22:49 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e4f8c88cf6f0 Added tag hs20-b06 for changeset e24ab3fa6aaf ! .hgtags Changeset: 76d6282dcfe5 Author: trims Date: 2011-01-13 22:53 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/76d6282dcfe5 7012348: Bump the HS20 build number to 07 Summary: Update the HS20 build number to 07 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 55f868e91c3b Author: iveresov Date: 2011-01-06 16:03 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/55f868e91c3b 7010618: C1: array length should be treated at int on 64bit during array allocation Summary: Sign-extend the length argument during array allocation Reviewed-by: never, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 0e52ef6e94d3 Author: twisti Date: 2011-01-07 03:58 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0e52ef6e94d3 Merge Changeset: 4fc084dac61e Author: kvn Date: 2011-01-07 10:16 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4fc084dac61e 7009756: volatile variables could be broken throw reflection API Summary: Use Atomic::load() and Atomic::store() to access a volatile long. Reviewed-by: iveresov, jrose, dholmes, never ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp ! src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/share/vm/prims/unsafe.cpp Changeset: 78e248949382 Author: kvn Date: 2011-01-07 11:53 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/78e248949382 6876037: CTW fails jdk7/hotspot/src/share/vm/opto/type.cpp:2055. assert(bits,"Use TypePtr for NULL") Summary: Add missing 0 value check in TypeRawPtr::add_offset(). Reviewed-by: never ! src/share/vm/opto/type.cpp Changeset: d810e9a3fc33 Author: twisti Date: 2011-01-10 00:56 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d810e9a3fc33 7010180: JSR 292 InvokeDynamicPrintArgs fails with: assert(_adapter == NULL) failed: init'd to NULL Reviewed-by: never ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 70427f06ea47 Author: twisti Date: 2011-01-10 03:58 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/70427f06ea47 7010913: JSR 292 ciMethodHandle does not handle MethodHandleCompiler exceptions properly Reviewed-by: kvn, never ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/prims/methodHandleWalk.cpp Changeset: dd031b2226de Author: iveresov Date: 2011-01-10 18:46 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/dd031b2226de 4930919: race condition in MDO creation at back branch locations Summary: Reuse set_method_data_for_bcp() to setup mdp after MDO creation. Reviewed-by: kvn, never ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp Changeset: d4fca0a6abde Author: kvn Date: 2011-01-11 20:26 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d4fca0a6abde 7011386: race in objArrayKlass::array_klass_impl Summary: Move _lower_dimension field initialization before _higher_dimension and add storestore barrier. Reviewed-by: dholmes, iveresov, never ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: bb8e3b66bde6 Author: twisti Date: 2011-01-13 07:20 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bb8e3b66bde6 Merge ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il Changeset: c17b998c5926 Author: iveresov Date: 2011-01-12 18:33 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c17b998c5926 7011627: C1: call_RT must support targets that don't fit in wdisp30 Summary: Make both compilers emit near and far calls when necessary. Reviewed-by: never, kvn, phh ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/sparc.ad Changeset: 5ae3e3b03224 Author: twisti Date: 2011-01-13 07:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5ae3e3b03224 Merge ! src/cpu/sparc/vm/assembler_sparc.hpp Changeset: df307487d610 Author: dholmes Date: 2011-01-09 17:16 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/df307487d610 7010665: Misplaced membar in C1 implementation of Unsafe.get/putXXX Summary: Modify membars to match regular volatile variable handling Reviewed-by: iveresov, kvn, never ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: e31d8c656c5b Author: dcubed Date: 2011-01-10 09:23 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e31d8c656c5b Merge ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 7246a374a9f2 Author: kamg Date: 2011-01-10 17:14 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7246a374a9f2 6458402: 3 jvmti tests fail with CMS and +ExplicitGCInvokesConcurrent Summary: Make JvmtiGCMark safe to run non-safepoint and instrument CMS Reviewed-by: ysr, dcubed ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/jniHandles.cpp Changeset: db2b0f8c1cef Author: kamg Date: 2011-01-11 10:06 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/db2b0f8c1cef 6814943: getcpool001 catches more than one JvmtiThreadState problem Summary: Mark field volatile, use membars, and change access order to close race Reviewed-by: dcubed, dholmes ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 5577848f5923 Author: phh Date: 2011-01-11 17:33 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5577848f5923 7011463: Sparc MacroAssembler::incr_allocated_bytes() needs a RegisterOrConstant argument Summary: Replaced incr_allocated_bytes() formals var_size_in_bytes and con_size_in_bytes with a single RegisterOrConstant formal. Reviewed-by: twisti, jcoomes ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp Changeset: 0ca32cc95d7b Author: phh Date: 2011-01-11 17:50 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0ca32cc95d7b Merge Changeset: 8f8dfba37802 Author: kevinw Date: 2011-01-12 15:44 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8f8dfba37802 6994753: Implement optional hook to a Java method at VM startup. Reviewed-by: mchung, acorn ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/thread.cpp Changeset: 34d64ad817f4 Author: coleenp Date: 2011-01-12 13:59 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/34d64ad817f4 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined Summary: Change get_temp_directory() back to /tmp and %TEMP% like it always was and where the tools expect it to be. Reviewed-by: phh, dcubed, kamg, alanb ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 856ecff79cf7 Author: dcubed Date: 2011-01-13 08:32 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/856ecff79cf7 Merge ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp Changeset: 4947ee68d19c Author: ysr Date: 2011-01-06 23:50 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4947ee68d19c 7008136: CMS: assert((HeapWord*)nextChunk <= _limit) failed: sweep invariant Summary: The recorded _sweep_limit may not necessarily remain a block boundary as the old generation expands during a concurrent cycle. Terminal actions inside the sweep closure need to be aware of this as they cross over the limit. Reviewed-by: johnc, minqi ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp Changeset: 2250ee17e258 Author: tonyp Date: 2011-01-12 13:06 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2250ee17e258 7007068: G1: refine the BOT during evac failure handling Summary: During evacuation failure handling we refine the BOT to reflect the location of all the objects in the regions we scan. The changeset includes some minor cleanup: a) non-product print_on() method on the G1 BOT class, b) added more complete BOT verification during heap / region verification, c) slight modification to the BOT set up for humongous regions to be more consistent with the BOT set up during evac failure handling, and d) removed a couple of unused methods. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: b158bed62ef5 Author: tonyp Date: 2011-01-12 16:34 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b158bed62ef5 6994297: G1: do first-level slow-path allocations with a CAS Summary: First attempt to allocate out the current alloc region using a CAS instead of taking the Heap_lock (first level of G1's slow allocation path). Only if that fails and it's necessary to replace the current alloc region take the Heap_lock (that's the second level of G1's slow allocation path). Reviewed-by: johnc, brutisso, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 2e0b0c4671e4 Author: brutisso Date: 2011-01-13 04:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2e0b0c4671e4 6941122: G1: UseLargePages does not work with G1 garbage collector Summary: Pass the value of UseLargePages instead of false as the "large" parameter when reserving the G1 heap. Reviewed-by: tonyp, johnc, phh ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: c91cc404ca46 Author: ysr Date: 2011-01-13 11:33 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c91cc404ca46 7011940: iCMS: SIGSEGV in SweepClosure::do_already_free_chunk(FreeChunk*)+0x360 Summary: Revert a (relaxed version of the) bounds-check that was incorrectly removed in the fix for 7008136. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: ffd725ff6943 Author: johnc Date: 2011-01-13 17:19 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ffd725ff6943 Merge ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 0915f9be781c Author: trims Date: 2011-01-13 22:54 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0915f9be781c Merge Changeset: 75efcee5ac47 Author: minqi Date: 2010-10-07 13:49 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/75efcee5ac47 6966589: hs16-b08 causes java.lang.StackOverflowError Reviewed-by: mchung, dholmes, chrisphi ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp Changeset: 85c73c0edb06 Author: kvn Date: 2011-01-18 17:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/85c73c0edb06 7012965: Fix failed on sparc for 7009756: volatile variables could be broken throw reflection API Summary: Use LDX/STX on v9 and LDD/STD on v8 sparc for volatile long moves. Reviewed-by: never ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.il Changeset: b599a4c6c2df Author: iveresov Date: 2011-01-18 18:00 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b599a4c6c2df 7012766: assert(false) failed: DEBUG MESSAGE in MacroAssembler::debug32 Summary: Interpreter expects to see methodOop in rbx on method entry, which needs to be restored after call to profile_method. Reviewed-by: kvn, never ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp Changeset: 8012aa3ccede Author: never Date: 2011-01-13 22:15 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8012aa3ccede 4926272: methodOopDesc::method_from_bcp is unsafe Reviewed-by: coleenp, jrose, kvn, dcubed ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodBlocks.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/methodLiveness.cpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeStream.cpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/relocator.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/vframeArray.cpp Changeset: 17c778814856 Author: coleenp Date: 2011-01-14 13:47 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/17c778814856 6811367: Fix code in HeapDumper::dump_heap() to avoid buffer overrun Summary: Check buffer size before using and use dynamic buffer sizes for subsequent calls. Reviewed-by: kamg, dholmes ! src/share/vm/services/heapDumper.cpp Changeset: 633a44a9fc45 Author: dcubed Date: 2011-01-19 07:15 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/633a44a9fc45 Merge ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp Changeset: c1a0ede55d6f Author: dcubed Date: 2011-01-19 07:41 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c1a0ede55d6f 7012493: 2/2 6849574/Test.java fails with Internal Error (src/share/vm/prims/jvmtiTagMap.cpp:3294) Summary: Refine assertion to work before VMThread has started. Reviewed-by: ysr, never, dholmes, acorn ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 2f33b03bd915 Author: never Date: 2011-01-19 08:16 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2f33b03bd915 7013008: 2/3 assert(method == NULL || check_method(method, bcp)) failed: bcp must point into method Summary: The Relocator should pass a NULL methodOop when rewriting since its resource array can never contain breakpoints. Reviewed-by: dcubed, kvn, coleenp ! src/share/vm/runtime/relocator.hpp Changeset: 9afee0b9fc1d Author: kamg Date: 2011-01-19 13:51 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9afee0b9fc1d 7012505: BreakpointWithFullGC.sh fails with Internal Error (src/share/vm/oops/methodOop.cpp:220) Summary: Rebuild breakpoint cache at gc_epilogue instead of during oops_do Reviewed-by: dcubed, ysr, coleenp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/runtime/jniHandles.cpp Changeset: 02b6913287da Author: dcubed Date: 2011-01-19 19:24 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/02b6913287da Merge Changeset: 7e37af9d69ef Author: tonyp Date: 2011-01-19 09:35 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7e37af9d69ef 7011379: G1: overly long concurrent marking cycles Summary: This changeset introduces filtering of SATB buffers at the point when they are about to be enqueued. If this filtering clears enough entries on each buffer, the buffer can then be re-used and not enqueued. This cuts down the number of SATB buffers that need to be processed by the concurrent marking threads. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: 182e9624aa42 Author: johnc Date: 2011-01-19 13:01 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/182e9624aa42 7012642: G1: JumbleGC002 test aborts with segmentation violation due to uncaught stack overflow Summary: With recent G1 allocation path changes, the value of StackShadowPages in fast debug builds of the JVM, is no longer large enough to prevent the JVM C++ code from touching the stack guard pages. Increase the value of StackShadowPages to a suitable value. Reviewed-by: ysr, tonyp, coleenp ! src/cpu/x86/vm/globals_x86.hpp Changeset: cb913d743d09 Author: johnc Date: 2011-01-19 13:04 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/cb913d743d09 Merge Changeset: 0fa27f37d4d4 Author: tonyp Date: 2011-01-19 19:30 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0fa27f37d4d4 6977804: G1: remove the zero-filling thread Summary: This changeset removes the zero-filling thread from G1 and collapses the two free region lists we had before (the "free" and "unclean" lists) into one. The new free list uses the new heap region sets / lists abstractions that we'll ultimately use it to keep track of all regions in the heap. A heap region set was also introduced for the humongous regions. Finally, this change increases the concurrency between the thread that completes freeing regions (after a cleanup pause) and the rest of the system (before we'd have to wait for said thread to complete before allocating a new region). The changest also includes a lot of refactoring and code simplification. Reviewed-by: jcoomes, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp + src/share/vm/gc_implementation/g1/heapRegionSet.cpp + src/share/vm/gc_implementation/g1/heapRegionSet.hpp + src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp + src/share/vm/gc_implementation/g1/heapRegionSets.cpp + src/share/vm/gc_implementation/g1/heapRegionSets.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 377371490991 Author: johnc Date: 2011-01-20 13:57 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/377371490991 Merge - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp Changeset: 5668ad215b80 Author: trims Date: 2011-01-20 17:53 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5668ad215b80 Merge ! .hgtags Changeset: 98bf1c6bb73a Author: trims Date: 2011-01-20 18:24 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/98bf1c6bb73a Merge Changeset: 85330eaa15ee Author: iveresov Date: 2011-01-21 00:01 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/85330eaa15ee 7013812: C1: deopt blob too far from patching stub Summary: Use long jumps to get from patching stubs to deopt blob Reviewed-by: kvn, never ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp Changeset: d535bf4c1235 Author: trims Date: 2011-01-21 02:07 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d535bf4c1235 Merge Changeset: 9a5762f44859 Author: trims Date: 2011-02-01 18:57 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9a5762f44859 Merge ! .hgtags - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp Changeset: 6ecdca5709df Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6ecdca5709df Added tag jdk7-b128 for changeset 9a5762f44859 ! .hgtags Changeset: 6aa467001334 Author: trims Date: 2011-01-25 14:57 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6aa467001334 Added tag hs20-b07 for changeset d535bf4c1235 ! .hgtags Changeset: d19d8218a399 Author: trims Date: 2011-01-25 15:06 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d19d8218a399 7014711: Fork HS20 to HS21 - renumber Major and build numbers of JVM Summary: Update the Major and Build numbers for HS21 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ccfcb502af3f Author: dholmes Date: 2011-01-25 00:14 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ccfcb502af3f 6566340: Restore use of stillborn flag to signify a thread that was stopped before it started Summary: Restore use of stillborn flag Reviewed-by: acorn, alanb ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/thread.cpp Changeset: 515cc1a31fd1 Author: dcubed Date: 2011-01-26 21:26 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/515cc1a31fd1 Merge Changeset: bb2c2878f134 Author: twisti Date: 2011-01-20 08:25 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bb2c2878f134 7011839: JSR 292 turn on escape analysis when using invokedynamic Summary: Currently escape analysis is turned off when EnableInvokeDynamic is true. Reviewed-by: jrose, kvn ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/runtime/arguments.cpp Changeset: a7367756024b Author: twisti Date: 2011-01-21 01:16 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a7367756024b Merge ! src/share/vm/ci/bcEscapeAnalyzer.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp Changeset: 403dc4c1d7f5 Author: never Date: 2011-01-21 13:01 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/403dc4c1d7f5 6809483: hotspot:::method_entry are not correctly generated for "method()V" Reviewed-by: iveresov, twisti ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: aa4b04b68652 Author: never Date: 2011-01-21 13:03 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/aa4b04b68652 Merge ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: e4fee0bdaa85 Author: never Date: 2011-01-24 13:34 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e4fee0bdaa85 7008809: should report the class in ArrayStoreExceptions from compiled code Reviewed-by: iveresov, twisti ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp Changeset: f966c66b5463 Author: iveresov Date: 2011-01-25 14:38 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f966c66b5463 7014247: CTW fails when compile sun/misc/AtomicLongCSImpl (REMOVED from JDK7) Summary: Use lea to compute field address in AtomicLongCSImpl::attemptUpdate() intrinsic on x86. Reviewed-by: never, kvn ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: 635b068a7224 Author: twisti Date: 2011-01-27 08:47 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/635b068a7224 Merge ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp Changeset: 9846d99e16d3 Author: twisti Date: 2011-01-27 14:05 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9846d99e16d3 Merge Changeset: a672e43650cc Author: tonyp Date: 2011-01-21 11:30 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a672e43650cc 7013718: G1: small fixes for two assert/guarantee failures Summary: Two small fixes to deal with a guarantee failure (the marking thread should join the SuspendibleThreadSet before calling a method that does pause prediction work so that said method is never called during a pause) and an assert failure (an assert is too strong). Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: 97ba643ea3ed Author: tonyp Date: 2011-01-25 17:58 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/97ba643ea3ed 7014261: G1: RSet-related failures Summary: A race between the concurrent cleanup thread and the VM thread while it is processing the "expanded sparse table list" causes both threads to try to free the same sparse table entry and either causes one of the threads to fail or leaves the entry in an inconsistent state. The solution is purge all entries on the expanded list that correspond go regions that are being cleaned up. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: 234761c55641 Author: johnc Date: 2011-01-25 10:56 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/234761c55641 6608385: G1: need to support parallel reference processing Summary: Implement support for ParallelRefProcEnabled in the reference processing that takes place at the end of G1 concurrent marking. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 81668b1f4877 Author: johnc Date: 2011-01-26 09:57 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/81668b1f4877 Merge ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 27e4ea99855d Author: johnc Date: 2011-01-27 13:42 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/27e4ea99855d Merge ! src/share/vm/runtime/arguments.cpp Changeset: 3582bf76420e Author: coleenp Date: 2011-01-27 16:11 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3582bf76420e 6990754: Use native memory and reference counting to implement SymbolTable Summary: move symbols from permgen into C heap and reference count them Reviewed-by: never, acorn, jmasa, stefank ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithKlass.java ! agent/src/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/PlaceholderEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/StringTable.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java - agent/src/share/classes/sun/jvm/hotspot/oops/SymbolKlass.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/types/Field.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp - src/share/vm/ci/ciSymbolKlass.cpp - src/share/vm/ci/ciSymbolKlass.hpp ! src/share/vm/ci/compilerInterface.hpp ! src/share/vm/classfile/classFileError.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/javaAssertions.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/resolutionErrors.cpp ! src/share/vm/classfile/resolutionErrors.hpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/compilerOracle.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/memory/classify.cpp ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/restore.cpp ! src/share/vm/memory/serialize.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/generateOopMap.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlassKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp + src/share/vm/oops/symbol.cpp + src/share/vm/oops/symbol.hpp - src/share/vm/oops/symbolKlass.cpp - src/share/vm/oops/symbolKlass.hpp - src/share/vm/oops/symbolOop.cpp - src/share/vm/oops/symbolOop.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fieldType.cpp ! src/share/vm/runtime/fieldType.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/interfaceSupport.cpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/rframe.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/hashtable.inline.hpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! src/share/vm/utilities/xmlstream.cpp ! src/share/vm/utilities/xmlstream.hpp Changeset: ae4b185f2ed1 Author: trims Date: 2011-02-03 23:26 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ae4b185f2ed1 Merge ! .hgtags - agent/src/share/classes/sun/jvm/hotspot/oops/SymbolKlass.java - src/share/vm/ci/ciSymbolKlass.cpp - src/share/vm/ci/ciSymbolKlass.hpp - src/share/vm/oops/symbolKlass.cpp - src/share/vm/oops/symbolKlass.hpp - src/share/vm/oops/symbolOop.cpp - src/share/vm/oops/symbolOop.hpp Changeset: 55b9f498dbce Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/55b9f498dbce Added tag jdk7-b129 for changeset ae4b185f2ed1 ! .hgtags Changeset: 14c2f31280dd Author: trims Date: 2011-02-11 14:30 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/14c2f31280dd Added tag hs21-b01 for changeset ae4b185f2ed1 ! .hgtags Changeset: b7a938236e43 Author: tonyp Date: 2011-01-31 16:28 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b7a938236e43 7014679: G1: deadlock during concurrent cleanup Summary: There's a potential deadlock between the concurrent cleanup thread and the GC workers that are trying to allocate and waiting for more free regions to be made available. Reviewed-by: iveresov, jcoomes ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: e49cfa28f585 Author: ysr Date: 2011-02-01 10:02 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e49cfa28f585 6999988: CMS: Increased fragmentation leading to promotion failure after CR#6631166 got implemented Summary: Fix calculation of _desired, in free list statistics, which was missing an intended set of parentheses. Reviewed-by: poonam, jmasa ! src/share/vm/gc_implementation/shared/allocationStats.hpp Changeset: 986b2844f7a2 Author: brutisso Date: 2011-02-01 14:05 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/986b2844f7a2 6789220: CMS: intermittent timeout running nsk/regression/b4796926 Summary: The reference handler java thread and the GC could dead lock Reviewed-by: never, johnc, jcoomes ! src/share/vm/compiler/compileBroker.cpp Changeset: c33825b68624 Author: johnc Date: 2011-02-02 10:41 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c33825b68624 6923430: G1: assert(res != 0,"This should have worked.") 7007446: G1: expand the heap with a single step, not one region at a time Summary: Changed G1CollectedHeap::expand() to expand the committed space by calling VirtualSpace::expand_by() once rather than for every region in the expansion amount. This allows the success or failure of the expansion to be determined before creating any heap regions. Introduced a develop flag G1ExitOnExpansionFailure (false by default) that, when true, will exit the VM if the expansion of the committed space fails. Finally G1CollectedHeap::expand() returns a status back to it's caller so that the caller knows whether to attempt the allocation. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 176d0be30214 Author: phh Date: 2011-02-03 16:06 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/176d0be30214 7016998: gcutil class LinearLeastSquareFit doesn't initialize some of its fields Summary: Initialize _sum_x_squared, _intercept and _slope in constructor. Reviewed-by: bobv, coleenp ! src/share/vm/gc_implementation/shared/gcUtil.cpp Changeset: c6bf3ca2bb31 Author: trims Date: 2011-02-04 16:29 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c6bf3ca2bb31 Merge Changeset: d70fe6ab4436 Author: coleenp Date: 2011-02-01 11:23 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d70fe6ab4436 6588413: Use -fvisibility=hidden for gcc compiles Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT to visibility=default, add for jio_snprintf and others since -fvisibility=hidden overrides --version-script definitions. Reviewed-by: kamg, never ! make/linux/makefiles/gcc.make ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/x86/vm/jni_x86.h ! src/cpu/zero/vm/jni_zero.h ! src/os/linux/vm/jvm_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: b92c45f2bc75 Author: bobv Date: 2011-02-02 11:35 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b92c45f2bc75 7016023: Enable building ARM and PPC from src/closed repository Reviewed-by: dholmes, bdelsart ! make/Makefile + make/closed.make ! make/jprt.properties ! make/linux/Makefile ! make/linux/makefiles/adlc.make + make/linux/makefiles/arm.make ! make/linux/makefiles/buildtree.make + make/linux/makefiles/ppc.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make + make/linux/platform_arm + make/linux/platform_ppc ! src/os/linux/vm/osThread_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/linux/vm/thread_linux.inline.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Defs.hpp ! src/share/vm/c1/c1_FpuStackSim.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/icBuffer.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/vmreg.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/cppInterpreterGenerator.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/interpreterGenerator.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jni_md.h ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/icache.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/registerMap.hpp ! src/share/vm/runtime/relocator.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/stackValueCollection.cpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/threadLocalStorage.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/copy.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 9cd8a2c2d584 Author: bobv Date: 2011-02-02 11:54 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9cd8a2c2d584 Merge ! src/os/linux/vm/os_linux.cpp Changeset: face83fc8882 Author: coleenp Date: 2011-02-02 18:38 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/face83fc8882 7012088: jump to 0 address because of lack of memory ordering in SignatureHandlerLibrary::add Summary: Write method signature handler under lock to prevent race with growable array resizing Reviewed-by: dsamersoff, dholmes ! src/share/vm/interpreter/interpreterRuntime.cpp Changeset: bf8517f4e4d0 Author: kamg Date: 2011-02-02 14:38 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bf8517f4e4d0 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" Summary: Defer posting events from the compiler thread: use service thread Reviewed-by: coleenp, dholmes, never, dcubed - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java + agent/src/share/classes/sun/jvm/hotspot/runtime/ServiceThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Thread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp + src/share/vm/runtime/serviceThread.cpp + src/share/vm/runtime/serviceThread.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/services/lowMemoryDetector.hpp ! src/share/vm/services/management.cpp ! src/share/vm/utilities/macros.hpp Changeset: d28def44457d Author: coleenp Date: 2011-02-03 21:30 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d28def44457d 7017009: Secondary out of c-heap memory error reporting out of memory Summary: Use os::malloc() to allocate buffer to read elf symbols and check for null Reviewed-by: zgu, phh, dsamersoff, dholmes, dcubed ! src/share/vm/utilities/elfSymbolTable.cpp Changeset: 5e139f767ddb Author: coleenp Date: 2011-02-03 20:30 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5e139f767ddb Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java Changeset: e9f24eebafd4 Author: rottenha Date: 2011-02-07 08:40 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e9f24eebafd4 Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java Changeset: d8a72fbc4be7 Author: kamg Date: 2011-02-08 17:20 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d8a72fbc4be7 7003401: Implement VM error-reporting functionality on erroneous termination Summary: Add support for distribution-specific error reporting Reviewed-by: coleenp, phh, jcoomes, ohair ! make/Makefile + make/altsrc.make - make/closed.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/top.make ! make/solaris/makefiles/vm.make ! make/windows/create_obj_files.sh ! make/windows/makefiles/vm.make ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp + src/share/vm/utilities/errorReporter.cpp + src/share/vm/utilities/errorReporter.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/vmError.cpp Changeset: fb539912d338 Author: coleenp Date: 2011-02-07 14:36 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/fb539912d338 6472925: OutOfMemoryError fails to generate stack trace as it now ought Summary: Print an additional message for OOM during stack trace printing Reviewed-by: dholmes, phh, acorn, kamg, dcubed ! src/share/vm/runtime/thread.cpp Changeset: 5fb3ee258e76 Author: coleenp Date: 2011-02-08 19:50 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5fb3ee258e76 Merge - make/closed.make Changeset: f36c9fe788b8 Author: mchung Date: 2011-02-08 09:11 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f36c9fe788b8 7017673: Remove setting of the sun.jkernel.DownloadManager as a boot classloader hook Reviewed-by: alanb, dcubed, coleenp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/thread.cpp Changeset: 5197f3d713a1 Author: mchung Date: 2011-02-08 22:27 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5197f3d713a1 Merge - make/closed.make ! src/share/vm/runtime/thread.cpp Changeset: 63d374c54045 Author: ctornqvi Date: 2011-02-09 11:08 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/63d374c54045 7014918: Improve core/minidump handling in Hotspot Summary: Added Minidump support on Windows, enabled large page core dumps when coredump_filter is present and writing out path/rlimit for core dumps. Reviewed-by: poonam, dsamersoff, sla, coleenp ! src/os/linux/vm/os_linux.cpp + src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: b83527d0482d Author: ctornqvi Date: 2011-02-10 12:55 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b83527d0482d 7018366: hotspot/runtime_erro Fix for 7014918 does not build using MVC 2003 Summary: Looking at API_VERSION_NUMBER define to see what version of dbghelp.h/imagehlp.h is included to determine what MINIDUMP_TYPEs are defined in the header file Reviewed-by: acorn, brutisso, sla ! src/os/windows/vm/os_windows.cpp Changeset: e1523f7fd848 Author: rottenha Date: 2011-02-11 05:40 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e1523f7fd848 Merge - make/closed.make Changeset: 2a9f9f2200fa Author: trims Date: 2011-02-11 15:31 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2a9f9f2200fa Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java Changeset: 762bc029de50 Author: trims Date: 2011-02-11 15:32 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/762bc029de50 7019104: Bump the HS21 build number to 02 Summary: Update the HS21 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e9aa2ca89ad6 Author: kamg Date: 2011-02-16 16:58 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e9aa2ca89ad6 7019718: make error reporting flags product instead of diagnostic Summary: see synopsis Reviewed-by: acorn, coleenp ! src/share/vm/runtime/globals.hpp Changeset: 0a2ecf4cc384 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0a2ecf4cc384 Added tag jdk7-b130 for changeset e9aa2ca89ad6 ! .hgtags Changeset: cdef89d821bd Author: ohair Date: 2011-02-16 13:30 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/cdef89d821bd 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 0aa3b4908911 Author: cl Date: 2011-02-23 15:48 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0aa3b4908911 Merge Changeset: 2015d9b41531 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2015d9b41531 Added tag jdk7-b131 for changeset 0aa3b4908911 ! .hgtags Changeset: f3e07ceeaed9 Author: trims Date: 2011-02-25 11:42 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f3e07ceeaed9 Added tag hs21-b02 for changeset e9aa2ca89ad6 ! .hgtags Changeset: 7dc5384467e0 Author: coleenp Date: 2011-02-12 10:28 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7dc5384467e0 7022659: errorHandler doesn't compile without precompiled headers Summary: add proper includes in errorHandler.hpp Reviewed-by: phh, kamg ! src/share/vm/utilities/errorReporter.hpp Changeset: 57053c7bee2c Author: mcimadamore Date: 2011-03-01 15:05 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/57053c7bee2c merge with jdk7-b131 - agent/src/share/classes/sun/jvm/hotspot/oops/SymbolKlass.java - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java - src/share/vm/ci/ciSymbolKlass.cpp - src/share/vm/ci/ciSymbolKlass.hpp - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp - src/share/vm/oops/symbolKlass.cpp - src/share/vm/oops/symbolKlass.hpp - src/share/vm/oops/symbolOop.cpp - src/share/vm/oops/symbolOop.hpp From maurizio.cimadamore at oracle.com Tue Mar 1 09:59:37 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 01 Mar 2011 17:59:37 +0000 Subject: The lambda conversion and a lambda body that doesn't complete. In-Reply-To: References: Message-ID: <4D6D3409.5090904@oracle.com> On 01/03/11 17:35, Neal Gafter wrote: > *interface F { > int invoke(); > }* > > I would like to be able to write > > *F x = #{ throw new Exception(); };* This works with lambda compiler: interface F { int invoke(); } class Test { F x = #{ throw new Exception(); }; public static void main(String[] args) { new Test().x.invoke(); } } Are you saying that the spec is not in sync with this? Maurizio From maurizio.cimadamore at oracle.com Tue Mar 1 10:18:16 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 01 Mar 2011 18:18:16 +0000 Subject: hg: lambda/lambda/langtools: 72 new changesets Message-ID: <20110301182036.B8A0847B86@hg.openjdk.java.net> Changeset: 4b0560c72b52 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/4b0560c72b52 Added tag jdk7-b124 for changeset 4868a36f6fd8 ! .hgtags Changeset: 62bdb6767734 Author: cl Date: 2011-01-13 16:44 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/62bdb6767734 Added tag jdk7-b125 for changeset 4b0560c72b52 ! .hgtags Changeset: a8d3eed8e247 Author: jjh Date: 2010-12-13 17:35 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a8d3eed8e247 6999460: Glassfish build with JDK 6 / 7 is 5x-10x slower on Windows than on Linux Summary: Fixed JavacFileManager to not treat a non-existant pathname as a directory. Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java Changeset: 0141f508b98d Author: jjg Date: 2010-12-14 14:17 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/0141f508b98d 6999891: DefaultFileManager incorrect Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + test/tools/javac/processing/filer/TestValidRelativeNames.java Changeset: cff0b8694633 Author: jjg Date: 2010-12-15 06:39 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/cff0b8694633 7006564: NPE in javac running test/tools/javac/nio/compileTest/CompileTest.java Reviewed-by: mcimadamore, alanb ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! test/tools/javac/nio/compileTest/CompileTest.java Changeset: 3131e664558d Author: ksrini Date: 2010-12-18 09:38 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3131e664558d 6567415: Neverending loop in ClassReader Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/6567415/T6567415.java Changeset: 7c33098600b2 Author: jjh Date: 2010-12-21 16:29 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7c33098600b2 7008378: javac bootstrap launcher fails on cygwin when called via an absolute path Summary: Use cygpath if it is cygwin Reviewed-by: ksrini ! make/Makefile ! make/build.xml ! src/share/bin/launcher.sh-template Changeset: 8859e49909e6 Author: lana Date: 2010-12-22 23:15 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/8859e49909e6 Merge Changeset: dd38bab326a3 Author: jjh Date: 2010-12-23 10:08 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/dd38bab326a3 7008869: Debug printlns accidentally added to make/build.xml Summary: Delete bogus echo statements Reviewed-by: ksrini ! make/build.xml Changeset: e8719f95f2d0 Author: jjh Date: 2010-12-23 12:29 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e8719f95f2d0 6982992: Tests CheckAttributedTree.java, JavacTreeScannerTest.java, and SourceTreeeScannerTest.java timeout Summary: Hoist some invariant code out of a loop Reviewed-by: ksrini ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/AbstractTreeScannerTest.java ! test/tools/javac/tree/TreePosTest.java Changeset: e63b1f8341ce Author: lana Date: 2011-01-04 17:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e63b1f8341ce Merge ! make/Makefile ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! test/tools/javac/nio/compileTest/CompileTest.java Changeset: 15484cb7e5ae Author: mcimadamore Date: 2011-01-05 09:59 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/15484cb7e5ae 7010194: several langtools regression failures after JSR 292 changes (b123) Summary: Some regression tests rely on unsupported JSR 292 features Reviewed-by: jjg ! test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDyn.java - test/tools/javac/meth/InvokeDynTrans.java ! test/tools/javac/meth/XlintWarn.java Changeset: 20fec1b88bc1 Author: lana Date: 2011-01-13 15:05 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/20fec1b88bc1 Merge - test/tools/javac/meth/InvokeDyn.java - test/tools/javac/meth/InvokeDynTrans.java Changeset: 438a8ad60f7a Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/438a8ad60f7a Merge Changeset: 1e6094c33187 Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/1e6094c33187 Added tag jdk7-b126 for changeset 438a8ad60f7a ! .hgtags Changeset: d79e283c7d9b Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d79e283c7d9b Added tag jdk7-b127 for changeset 1e6094c33187 ! .hgtags Changeset: d17f37522154 Author: jjg Date: 2011-01-10 14:57 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d17f37522154 6992999: fully remove JSR 308 from langtools Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! test/tools/javac/diags/examples.not-yet.txt Changeset: 7c537f4298fb Author: jjg Date: 2011-01-10 15:08 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7c537f4298fb 6396503: javac should not require assertions enabled Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java + src/share/classes/com/sun/tools/javac/util/Assert.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/UnsharedNameTable.java ! src/share/classes/javax/tools/ToolProvider.java Changeset: 17b271281525 Author: jjg Date: 2011-01-11 08:05 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/17b271281525 6993305: starting position of a method without modifiers and with type parameters is incorrect Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/tree/T6993305.java Changeset: d33d8c381aa1 Author: jjg Date: 2011-01-13 11:48 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d33d8c381aa1 6430241: Hard to disable symbol file feature through API Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java + test/tools/javac/api/T6430241.java Changeset: a466f00c5cd2 Author: bpatel Date: 2011-01-13 21:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a466f00c5cd2 7010528: javadoc performance regression Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java Changeset: 2d5aff89aaa3 Author: mcimadamore Date: 2011-01-14 09:45 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2d5aff89aaa3 6992698: JSR 292: remove support for transient syntax in polymorphic signature calls Summary: special syntax to denote indy return type through type parameters should be removed (and cast shall be used instead) Reviewed-by: jjg, jrose ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/Names.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out ! test/tools/javac/meth/TestCP.java ! test/tools/javac/meth/XlintWarn.java Changeset: c8d312dd17bc Author: mcimadamore Date: 2011-01-14 09:45 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c8d312dd17bc 7007432: Test generic types well-formedness Summary: add a new kind of check (well-formedness of generic type w.r.t. declared bounds) in the type-harness Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/types/GenericTypeWellFormednessTest.java ! test/tools/javac/types/TypeHarness.java Changeset: 712be35e40b5 Author: mcimadamore Date: 2011-01-14 09:46 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/712be35e40b5 6949040: java.dyn package must be compiled with -target 7 or better Summary: issue error (rather than warning) when @PolymorphicSignature is found and target < 7 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt Changeset: 7c7c1787fbbe Author: jjg Date: 2011-01-14 11:45 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7c7c1787fbbe 6419926: JSR 199: FileObject.toUri() generates URI without schema (Solaris) Reviewed-by: mcimadamore + test/tools/javac/api/T6419926.java Changeset: 0a509c765657 Author: jjg Date: 2011-01-14 11:55 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/0a509c765657 6571165: Minor doc bugs in JavaCompiler.java Reviewed-by: mcimadamore ! src/share/classes/javax/tools/JavaCompiler.java Changeset: 19f9b6548c70 Author: ksrini Date: 2011-01-14 13:59 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/19f9b6548c70 7011272: langtools build.xml should provide a patch target Reviewed-by: jonathan, jjh ! make/build.xml Changeset: 5cf6c432ef2f Author: ksrini Date: 2011-01-18 08:37 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/5cf6c432ef2f 6982999: tools must support -target 7 bytecodes Reviewed-by: jjg, jrose ! src/share/classes/com/sun/tools/classfile/Attribute.java + src/share/classes/com/sun/tools/classfile/BootstrapMethods_attribute.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java Changeset: b6f95173e769 Author: lana Date: 2011-01-19 19:01 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/b6f95173e769 Merge Changeset: 19c900c703c6 Author: mcimadamore Date: 2011-01-24 15:44 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/19c900c703c6 6943278: spurious error message for inference and type-variable with erroneous bound Summary: type-inference should ignore erroneous bounds Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/6943278/T6943278.java + test/tools/javac/generics/inference/6943278/T6943278.out Changeset: ce6175cfe11e Author: mcimadamore Date: 2011-01-24 15:44 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/ce6175cfe11e 6968793: issues with diagnostics Summary: several diagnostic improvements Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6304921/T6304921.out ! test/tools/javac/6330920/T6330920.out ! test/tools/javac/6717241/T6717241a.out ! test/tools/javac/6717241/T6717241b.out ! test/tools/javac/6857948/T6857948.out ! test/tools/javac/6863465/T6863465c.out ! test/tools/javac/6863465/T6863465d.out ! test/tools/javac/T6247324.out ! test/tools/javac/TryWithResources/ResourceOutsideTry.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/CantResolve.java ! test/tools/javac/diags/examples/CantResolveArgsParams.java ! test/tools/javac/diags/examples/CantResolveLocation.java ! test/tools/javac/diags/examples/CantResolveLocationArgs.java ! test/tools/javac/diags/examples/CantResolveLocationArgsParams.java - test/tools/javac/diags/examples/EnumConstRequired.java ! test/tools/javac/diags/examples/ForeachNotApplicable.java ! test/tools/javac/diags/examples/KindnameClass.java ! test/tools/javac/diags/examples/KindnameMethod.java ! test/tools/javac/diags/examples/KindnameVariable.java + test/tools/javac/diags/examples/Location.java + test/tools/javac/diags/examples/Location1.java ! test/tools/javac/diags/examples/OperatorCantBeApplied.java + test/tools/javac/diags/examples/OperatorCantBeApplied1.java ! test/tools/javac/diags/examples/StaticImportOnlyClassesAndInterfaces/StaticImportOnlyClassesAndInterfaces.java ! test/tools/javac/failover/FailOver01.out ! test/tools/javac/failover/FailOver02.out ! test/tools/javac/failover/FailOver04.out ! test/tools/javac/generics/6711619/T6711619a.out ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/diamond/neg/Neg02.out ! test/tools/javac/generics/diamond/neg/Neg03.out ! test/tools/javac/generics/diamond/neg/Neg04.out ! test/tools/javac/generics/diamond/neg/Neg11.out ! test/tools/javac/generics/inference/6943278/T6943278.out ! test/tools/javac/generics/typevars/5060485/Compatibility.out ! test/tools/javac/generics/typevars/5060485/Compatibility02.out + test/tools/javac/generics/typevars/6968793/T6968793.java + test/tools/javac/generics/typevars/6968793/T6968793.out ! test/tools/javac/policy/test1/byfile.ABD.out ! test/tools/javac/policy/test1/bytodo.ABD.out ! test/tools/javac/policy/test1/simple.ABD.out Changeset: 02e6e7dd1a64 Author: mcimadamore Date: 2011-01-24 15:45 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/02e6e7dd1a64 6510286: Wording of javac error for inner classes Summary: 'inner classes cannot have static declarations' message needs to be reworked Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/InnerNamedConstant_2.out Changeset: 812c6251ea78 Author: mcimadamore Date: 2011-01-24 15:45 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/812c6251ea78 6569633: Varargs: parser error when varargs element type is an array Summary: explicit error message when old-style array syntax is mixed with varargs 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/VarargsAndOldArraySyntax.java + test/tools/javac/varargs/6569633/T6569633.java + test/tools/javac/varargs/6569633/T6569633.out Changeset: 57e3b9bc7fb8 Author: mcimadamore Date: 2011-01-24 15:45 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/57e3b9bc7fb8 7013865: varargs: javac crashes during overload resolution with generic varargs Summary: fixed regression with varargs overload resolution that leads javac to crash Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/varargs/T7013865.java Changeset: 2314f2b07ae7 Author: lana Date: 2011-01-24 13:25 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2314f2b07ae7 Merge - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java - test/tools/javac/diags/examples/EnumConstRequired.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out Changeset: d7225b476a5d Author: lana Date: 2011-01-28 10:06 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d7225b476a5d Merge - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java - test/tools/javac/diags/examples/EnumConstRequired.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out Changeset: 1383d1ee8b5d Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/1383d1ee8b5d Added tag jdk7-b128 for changeset d7225b476a5d ! .hgtags Changeset: 03e7fc380090 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/03e7fc380090 Added tag jdk7-b129 for changeset 1383d1ee8b5d ! .hgtags Changeset: 73ab0b128918 Author: jjg Date: 2011-01-24 16:17 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/73ab0b128918 6963934: JCCompilationUnit.getImports does not report all imports Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/tree/T6963934.java Changeset: 22a040cbf0e0 Author: jjg Date: 2011-01-24 16:34 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/22a040cbf0e0 6581775: Fix the white space problem in javac shell tests Reviewed-by: mcimadamore ! test/tools/javac/ClassPathTest/ClassPathTest.sh ! test/tools/javac/ExtDirs/ExtDirs.sh ! test/tools/javac/Paths/Help.sh ! test/tools/javac/javazip/Test.sh ! test/tools/javac/versions/check.sh Changeset: a8437c34fdc7 Author: jjg Date: 2011-01-24 16:38 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a8437c34fdc7 6988106: javac report 'java.lang.IllegalMonitorStateException' Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java + src/share/classes/com/sun/tools/javac/file/ZipFileIndexCache.java ! test/tools/javac/T6725036.java Changeset: 7f8794f9cc14 Author: darcy Date: 2011-01-25 17:02 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7f8794f9cc14 7013420: Project Coin: remove general expression support from try-with-resources statement Reviewed-by: mcimadamore, jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/TryWithResources/BadTwrSyntax.out ! test/tools/javac/TryWithResources/DuplicateResource.java + test/tools/javac/TryWithResources/ExplicitFinal.java ! test/tools/javac/TryWithResources/ImplicitFinal.java ! test/tools/javac/TryWithResources/ImplicitFinal.out ! test/tools/javac/TryWithResources/TwrFlow.java ! test/tools/javac/TryWithResources/TwrFlow.out - test/tools/javac/TryWithResources/TwrInference.java - test/tools/javac/TryWithResources/TwrIntersection.java - test/tools/javac/TryWithResources/TwrIntersection02.java - test/tools/javac/TryWithResources/TwrIntersection02.out ! test/tools/javac/TryWithResources/TwrMultiCatch.java ! test/tools/javac/TryWithResources/TwrOnNonResource.java ! test/tools/javac/TryWithResources/TwrOnNonResource.out + test/tools/javac/diags/examples/TryResourceTrailingSemi.java Changeset: df371fd16386 Author: jjg Date: 2011-01-26 11:20 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/df371fd16386 6554097: "final" confuses @SuppressWarnings Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/T6554097.java + test/tools/javac/T6554097.out Changeset: 3da26790ccb7 Author: jjg Date: 2011-01-26 13:45 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3da26790ccb7 7013272: Automatically generate info about how compiler resource keys are used Reviewed-by: mcimadamore ! make/build.xml ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/ArgTypeCompilerFactory.java ! test/tools/javac/diags/Example.java + test/tools/javac/diags/MessageFile.java + test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java Changeset: 92ab09ed59fd Author: jjh Date: 2011-01-28 00:09 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/92ab09ed59fd 7015482: jtreg test tools/javac/diags/MessageInfo.java fails when test/ dir is not in langtools repo Summary: Don't fail if the needed file isn't present, if running under jtreg. Reviewed-by: jjg ! test/tools/javac/diags/MessageInfo.java Changeset: 2088e674f0e0 Author: mcimadamore Date: 2011-01-28 12:01 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2088e674f0e0 6910550: javac 1.5.0_17 fails with incorrect error message Summary: multiple clashing members declared in same class should be added to the class' scope in order to avoid downstream spurious diagnostics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/6910550/T6910550a.java + test/tools/javac/generics/6910550/T6910550a.out + test/tools/javac/generics/6910550/T6910550b.java + test/tools/javac/generics/6910550/T6910550b.out + test/tools/javac/generics/6910550/T6910550c.java + test/tools/javac/generics/6910550/T6910550c.out + test/tools/javac/generics/6910550/T6910550d.java + test/tools/javac/generics/6910550/T6910550d.out + test/tools/javac/generics/6910550/T6910550e.java + test/tools/javac/generics/6910550/T6910550e.out Changeset: 5a43b245aed1 Author: mcimadamore Date: 2011-01-28 12:03 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/5a43b245aed1 6313164: javac generates code that fails byte code verification for the varargs feature Summary: method applicability check should fail if formal varargs element type is not accessible Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/InaccessibleVarargsType/InaccessibleVarargsType.java + test/tools/javac/diags/examples/InaccessibleVarargsType/p1/A.java + test/tools/javac/diags/examples/InaccessibleVarargsType/p1/B.java ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712d.out + test/tools/javac/varargs/6313164/T6313164.java + test/tools/javac/varargs/6313164/T6313164.out + test/tools/javac/varargs/6313164/p1/A.java + test/tools/javac/varargs/6313164/p1/B.java + test/tools/javac/varargs/6313164/p1/C.java Changeset: 17bafae67e9d Author: mcimadamore Date: 2011-01-28 12:06 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/17bafae67e9d 6838943: inference: javac is not handling type-variable substitution properly Summary: free type-variables are being replaced with type-variables bound to forall type leading to unsoundness Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/inference/6838943/T6838943.java + test/tools/javac/generics/inference/6838943/T6838943.out Changeset: babf86a1ac92 Author: alanb Date: 2011-01-28 09:25 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/babf86a1ac92 7006126: (fs) Updates to file system API (1/2011) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! test/tools/javac/nio/compileTest/CompileTest.java Changeset: df3394337b04 Author: alanb Date: 2011-01-28 12:36 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/df3394337b04 Merge Changeset: 7a75a1803c7a Author: darcy Date: 2011-01-28 16:54 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7a75a1803c7a 7015530: Reiterate API specializations in javax.lang.model.elment subinterfaces Reviewed-by: jjg ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java ! src/share/classes/javax/lang/model/element/PackageElement.java ! src/share/classes/javax/lang/model/element/TypeElement.java ! src/share/classes/javax/lang/model/element/TypeParameterElement.java ! src/share/classes/javax/lang/model/element/VariableElement.java Changeset: 2ab47c4cd618 Author: darcy Date: 2011-01-31 19:06 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2ab47c4cd618 7014734: Project Coin: Allow optional trailing semicolon to terminate resources list in try-with-resources 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/TryWithResources/BadTwrSyntax.java ! test/tools/javac/TryWithResources/BadTwrSyntax.out - test/tools/javac/diags/examples/TryResourceTrailingSemi.java Changeset: cad51b6eb7a6 Author: darcy Date: 2011-02-01 10:11 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/cad51b6eb7a6 6961571: Update visitors to support ARM's ElementKind.RESOURCE_VARIABLE Reviewed-by: jjg + src/share/classes/javax/lang/model/type/DisjunctiveType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.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/ElementKindVisitor6.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor7.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/SimpleAnnotationValueVisitor7.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/SimpleTypeVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java ! src/share/classes/javax/lang/model/util/Types.java ! test/tools/javac/processing/model/element/TestResourceVariable.java Changeset: 899f7c3d9426 Author: mcimadamore Date: 2011-02-03 09:35 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/899f7c3d9426 6594914: @SuppressWarnings("deprecation") does not not work for the type of a variable Summary: Lint warnings generated during MemberEnter might ignore @SuppressWarnings annotations Reviewed-by: jjg + src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/warnings/6594914/DeprecatedClass.java + test/tools/javac/warnings/6594914/T6594914a.java + test/tools/javac/warnings/6594914/T6594914a.out + test/tools/javac/warnings/6594914/T6594914b.java + test/tools/javac/warnings/6594914/T6594914b.out Changeset: 875262e89b52 Author: mcimadamore Date: 2011-02-03 09:36 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/875262e89b52 5017953: spurious cascaded diagnostics when name not found Summary: when an operator is applied to one or more erroneous operands, spurious diagnostics are generated Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/5017953/T5017953.java + test/tools/javac/5017953/T5017953.out ! test/tools/javac/6491592/T6491592.out Changeset: 03cf47d4de15 Author: mcimadamore Date: 2011-02-03 09:37 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/03cf47d4de15 6969184: poor error recovery after symbol not found Summary: generic type-well formedness check should ignore erroneous symbols Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/6969184/T6969184.java + test/tools/javac/generics/6969184/T6969184.out Changeset: afe226180744 Author: mcimadamore Date: 2011-02-03 09:38 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/afe226180744 7014715: javac returns different error code for certain failure(s) Summary: javac silently crashes when emitting certain kinds of resolution diagnostics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/AnonStaticMember_2.java + test/tools/javac/AnonStaticMember_2.out ! test/tools/javac/InterfaceInInner.java + test/tools/javac/InterfaceInInner.out ! test/tools/javac/QualifiedNew.java + test/tools/javac/QualifiedNew.out ! test/tools/javac/T6247324.out ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/inference/6943278/T6943278.out Changeset: 9e6a09375d37 Author: lana Date: 2011-02-04 17:30 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/9e6a09375d37 Merge Changeset: 3aa269645199 Author: mcimadamore Date: 2011-02-07 18:09 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3aa269645199 7017414: before the move of JSR 292 to package java.lang.invoke, javac must recognize the new package Summary: added support for future 292 package (support for old location 'java.dyn' will be removed in followup changeset) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/util/Names.java Changeset: 96d4226bdd60 Author: mcimadamore Date: 2011-02-07 18:10 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/96d4226bdd60 7007615: java_util/generics/phase2/NameClashTest02 fails since jdk7/pit/b123. Summary: override clash algorithm is not implemented correctly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/NameClashSameErasureNoHide.java ! test/tools/javac/diags/examples/NameClashSameErasureNoOverride.java + test/tools/javac/diags/examples/NameClashSameErasureNoOverride1.java ! test/tools/javac/generics/5009937/T5009937.out ! test/tools/javac/generics/6182950/T6182950b.out ! test/tools/javac/generics/6476118/T6476118a.out ! test/tools/javac/generics/6476118/T6476118b.out ! test/tools/javac/generics/6476118/T6476118c.java ! test/tools/javac/generics/6476118/T6476118c.out ! test/tools/javac/generics/6985719/T6985719e.out ! test/tools/javac/generics/6985719/T6985719f.out ! test/tools/javac/generics/6985719/T6985719g.out ! test/tools/javac/generics/6985719/T6985719h.out + test/tools/javac/generics/7007615/T7007615.java + test/tools/javac/generics/7007615/T7007615.out + test/tools/javac/generics/7007615/acc1/AccessibilityCheck01.java + test/tools/javac/generics/7007615/acc1/p1/C.java + test/tools/javac/generics/7007615/acc1/p1/D.java + test/tools/javac/generics/7007615/acc1/p2/E.java + test/tools/javac/generics/7007615/acc2/AccessibilityCheck02.java + test/tools/javac/generics/7007615/acc2/AccessibilityCheck02.out + test/tools/javac/generics/7007615/acc2/p1/C.java + test/tools/javac/generics/7007615/acc2/p1/D.java + test/tools/javac/generics/7007615/acc2/p2/E.java ! test/tools/javac/scope/HashCollisionTest.java ! test/tools/javac/scope/StarImportTest.java Changeset: 56b77a38618c Author: jjg Date: 2011-02-07 11:42 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/56b77a38618c 7017675: typo in JavacParser for allowUnderscoresInLiterals Reviewed-by: dlsmith Contributed-by: peter.b.kessler at oracle.com ! src/share/classes/com/sun/tools/javac/parser/Scanner.java Changeset: 2cbaa43eb075 Author: lana Date: 2011-02-14 16:31 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2cbaa43eb075 Merge - test/tools/javac/TryWithResources/TwrInference.java - test/tools/javac/TryWithResources/TwrIntersection.java - test/tools/javac/TryWithResources/TwrIntersection02.java - test/tools/javac/TryWithResources/TwrIntersection02.out Changeset: a21c7f194d31 Author: mfang Date: 2011-02-10 16:51 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a21c7f194d31 7017734: jdk7 message drop 1 translation integration Reviewed-by: ogino, yhuang ! src/share/classes/com/sun/tools/apt/resources/apt_ja.properties ! src/share/classes/com/sun/tools/apt/resources/apt_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties Changeset: 4cdea0752a48 Author: mfang Date: 2011-02-11 22:58 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/4cdea0752a48 Merge Changeset: 26071d11c613 Author: mfang Date: 2011-02-11 23:49 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/26071d11c613 Merge Changeset: 7a98db8cbfce Author: ohair Date: 2011-02-15 12:34 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7a98db8cbfce Merge Changeset: 6cdb76cf4d1a Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6cdb76cf4d1a Added tag jdk7-b130 for changeset 7a98db8cbfce ! .hgtags Changeset: 22ea7d483794 Author: ohair Date: 2011-02-16 13:30 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/22ea7d483794 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 67221b8643b4 Author: cl Date: 2011-02-23 15:49 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/67221b8643b4 Merge Changeset: 80bbd1da4a72 Author: cl Date: 2011-02-24 15:16 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/80bbd1da4a72 Added tag jdk7-b131 for changeset 67221b8643b4 ! .hgtags Changeset: 3240fef7f13e Author: mcimadamore Date: 2011-03-01 15:02 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3240fef7f13e merge with jdk7-b131 ! make/build.xml ! src/share/bin/launcher.sh-template ! src/share/classes/com/sun/runtime/ProxyHelper.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! src/share/classes/javax/lang/model/util/Types.java - test/tools/javac/TryWithResources/TwrInference.java - test/tools/javac/TryWithResources/TwrIntersection.java - test/tools/javac/TryWithResources/TwrIntersection02.java - test/tools/javac/TryWithResources/TwrIntersection02.out ! test/tools/javac/diags/examples.not-yet.txt - test/tools/javac/diags/examples/EnumConstRequired.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/diamond/neg/Neg02.out ! test/tools/javac/generics/diamond/neg/Neg03.out ! test/tools/javac/generics/diamond/neg/Neg04.out ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712d.out + test/tools/javac/generics/inference/6838943/T6838943.out ! test/tools/javac/generics/typevars/5060485/Compatibility.out ! test/tools/javac/generics/typevars/5060485/Compatibility02.out ! test/tools/javac/lambda/BadLambdaPos.out - test/tools/javac/meth/InvokeDyn.java - test/tools/javac/meth/InvokeDynTrans.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out ! test/tools/javac/transparency/Neg03.out ! test/tools/javac/types/TypeHarness.java + test/tools/javac/varargs/6313164/T6313164.out Changeset: 5aeda537bf98 Author: mcimadamore Date: 2011-03-01 17:48 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/5aeda537bf98 Fix: wrong subtyping implementation for disjunctive types. Wrong subtyping between disjunctive types caused errors in method resolution. ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/DisjunctiveTypeTest.java From brian.goetz at oracle.com Tue Mar 1 11:10:19 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 1 Mar 2011 11:10:19 -0800 Subject: The lambda conversion and a lambda body that doesn't complete. In-Reply-To: References: Message-ID: Neal; Thanks for the note. You're right that the current prototype doesn't deal with this properly. The good news is that the draft spec we're working on -- and will present to the JSR 335 EG soon -- already addresses this issue. On Mar 1, 2011, at 9:35 AM, Neal Gafter wrote: > Dear Lambdans- > > Given > > *interface F { > int invoke(); > }* > > I would like to be able to write > > *F x = #{ throw new Exception(); }; > * > > (Modulo syntax - whatever the current syntax is) > > But according to the current draft specification that's not allowed (the > lambda as written can only be converted to a SAM with a void return type). > > I think that whether or not the lambda's body can complete normally should > be taken into account in the lambda conversion to make this legal. As a > point of information, the behavior I prefer is the behavior of Scala, BGGA, > and C# (among others). This is also consistent with the way method > implementations work: > > *int f() { throw new Exception(); }* > > In the unfortunate case that you need use cases for this, draft > specification language, or suggestions for a straightforward implementation, > I can provide those. > > Cheers, > Neal > From neal at gafter.com Tue Mar 1 13:04:35 2011 From: neal at gafter.com (Neal Gafter) Date: Tue, 1 Mar 2011 13:04:35 -0800 Subject: The lambda conversion and a lambda body that doesn't complete. In-Reply-To: References: Message-ID: Maurizio and Brian- You make me very happy. Cheers, Neal From maurizio.cimadamore at oracle.com Tue Mar 1 09:57:23 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 01 Mar 2011 17:57:23 +0000 Subject: hg: lambda/lambda/jdk: 266 new changesets Message-ID: <20110301184035.2770D47B87@hg.openjdk.java.net> Changeset: 0a56bdd709d0 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0a56bdd709d0 Added tag jdk7-b124 for changeset 1c72adc9d5f3 ! .hgtags Changeset: 3972926bc8f1 Author: cl Date: 2011-01-13 16:44 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3972926bc8f1 Added tag jdk7-b125 for changeset 0a56bdd709d0 ! .hgtags Changeset: 4d6f9aaa2600 Author: flar Date: 2010-12-14 13:25 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4d6f9aaa2600 6766342: Improve performance of Ductus rasterizer Reviewed-by: jgodinez, prr ! make/sun/awt/make.depend ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/loops/CompositeType.java ! src/share/classes/sun/java2d/loops/MaskFill.java ! src/share/classes/sun/java2d/pipe/AAShapePipe.java ! src/share/classes/sun/java2d/pipe/AlphaColorPipe.java ! src/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/native/sun/java2d/loops/DrawParallelogram.c ! src/share/native/sun/java2d/loops/FillParallelogram.c ! src/share/native/sun/java2d/loops/MaskFill.c + src/share/native/sun/java2d/loops/ParallelogramUtils.h ! src/solaris/native/sun/java2d/loops/vis_IntArgbPre_Mask.c ! src/solaris/native/sun/java2d/loops/vis_SrcMaskFill.c + test/java/awt/Graphics2D/RenderClipTest/6766342.tests + test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java Changeset: 9d0eebb55003 Author: bae Date: 2010-12-15 19:47 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9d0eebb55003 6782574: AffineTransformOp.filter(BufferedImage, BufferedImage) fails with InternalError Reviewed-by: igor, prr ! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java ! src/share/native/sun/awt/image/awt_parseImage.c + test/java/awt/image/IncorrectSampleMaskTest.java Changeset: 6a219e5ccfd7 Author: bae Date: 2010-12-17 13:18 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6a219e5ccfd7 7006948: FindBugs warning in IndexColorModel class Reviewed-by: igor, prr ! src/share/classes/java/awt/image/IndexColorModel.java Changeset: 33a0f66771d5 Author: jgodinez Date: 2010-12-17 09:39 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/33a0f66771d5 6635462: D3D: REGRESSION: XOR rendering is extremly slow Reviewed-by: igor, prr ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java Changeset: 0125062d65b6 Author: bae Date: 2010-12-20 10:38 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0125062d65b6 6736178: java.awt.image.SampleModel constructor unexpectedly throws IllegalArgumentException Reviewed-by: jgodinez, prr ! src/share/classes/java/awt/image/SampleModel.java Changeset: b0f9760f3103 Author: prr Date: 2010-12-22 13:32 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b0f9760f3103 7007299: FileFontStrike appears not to be threadsafe? Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FileFontStrike.java Changeset: 1513ccf103a9 Author: prr Date: 2010-12-22 13:49 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1513ccf103a9 6996867: Garbage rendering of LCD text with SRC composite mode Reviewed-by: igor, jgodinez ! src/share/classes/sun/java2d/SurfaceData.java + test/java/awt/Graphics2D/DrawString/LCDTextSrcEa.java Changeset: 78d0a8d449fd Author: bae Date: 2010-12-23 14:27 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/78d0a8d449fd 7002627: JNI Critical Arrays should be released with the original (unmodified) pointer Reviewed-by: jgodinez, prr ! src/share/native/sun/java2d/pipe/BufferedMaskBlit.c Changeset: cb3c0ffb27bb Author: lana Date: 2010-12-23 00:03 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cb3c0ffb27bb Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - test/java/dyn/JavaDocExamples.java Changeset: 155d91257957 Author: lana Date: 2010-12-23 08:47 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/155d91257957 Merge Changeset: 7fff69f28bf4 Author: jgodinez Date: 2010-12-23 10:38 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7fff69f28bf4 6913300: Missing serialVersionUID in javax.print.attribute.standard.DialogTypeSelection Reviewed-by: igor, prr ! src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java Changeset: b22c74e20a1b Author: jgodinez Date: 2010-12-23 11:01 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b22c74e20a1b 6949749: regression cases need to be updated by removing "System.exit(0)" Reviewed-by: igor, prr ! test/java/awt/PrintJob/Text/StringWidth.java Changeset: 417acb7e8fa1 Author: prr Date: 2010-12-23 15:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/417acb7e8fa1 6891551: Font rasterisation uses more heap than needed for some strikes. Reviewed-by: jgodinez ! src/share/classes/sun/font/FileFontStrike.java Changeset: 4e47e55dd717 Author: prr Date: 2010-12-23 21:58 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4e47e55dd717 6927458: font system should cache transient strikes with weak references. Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/Font2D.java Changeset: 99c540ac926c Author: bae Date: 2010-12-24 14:05 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/99c540ac926c 6983028: java/awt/FontClass/FontPrivilege.java Reviewed-by: prr ! test/java/awt/FontClass/FontPrivilege.java Changeset: 14033e1600ac Author: prr Date: 2010-12-24 09:31 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/14033e1600ac 6997210: Solaris 11 has no development support for DGA: Cannot build JDK Reviewed-by: bae, ohair ! make/sun/Makefile Changeset: 70bfa0af3969 Author: bae Date: 2010-12-30 11:33 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/70bfa0af3969 7003434: test/closed/java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java fails with ClassCastExc Reviewed-by: jgodinez, prr ! src/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java Changeset: 9320dcfb5398 Author: lana Date: 2011-01-05 11:21 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9320dcfb5398 Merge - make/common/internal/BinaryPlugs.gmk ! make/sun/Makefile ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! src/share/classes/java/awt/image/IndexColorModel.java ! src/share/classes/java/awt/image/SampleModel.java ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/native/sun/java2d/loops/DrawParallelogram.c ! src/share/native/sun/java2d/loops/FillParallelogram.c ! src/windows/classes/sun/awt/windows/WComponentPeer.java Changeset: 3db5ac2b4c62 Author: andrew Date: 2010-12-14 13:51 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3db5ac2b4c62 6444769: java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html fails Summary: Remove unneeded test Reviewed-by: anthony - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java Changeset: b9706aff91a3 Author: lana Date: 2010-12-15 11:49 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b9706aff91a3 Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: 4a0970a420d5 Author: anthony Date: 2010-12-16 21:48 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4a0970a420d5 6993803: Request to update SplashScreen specification 6984255: Request for java.awt.SplashScreen spec update: mention possibility of having custom "-splash" option 6992416: [Spec clarification request] Is color deviation for splash screen image allowed? 6992833: [Spec clarification request] point (0,0) in SplashScreen.createGraphics() 6993071: java.awt.SplashScreen should mention that no unnecessary distortions to the image are allowed 6993113: [Spec clarification request] getSplashScreen(): null or HeadlessException? 6996439: [Spec clarification request] Is any delay with splashscreen appearance allowed? Summary: Update SplashScreen specification Reviewed-by: art ! src/share/classes/java/awt/SplashScreen.java Changeset: 8dbb797793b0 Author: anthony Date: 2010-12-22 17:37 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8dbb797793b0 6998323: Unexpected color change after invoking SplashScreen.update() Summary: Fix the blendRGB() function Reviewed-by: art, dcherepanov ! src/share/native/sun/awt/splashscreen/splashscreen_gfx_impl.h Changeset: 15c45fdd572c Author: lana Date: 2010-12-23 10:20 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/15c45fdd572c Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java Changeset: 6e4d9f4466f6 Author: dcherepanov Date: 2010-12-27 18:37 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6e4d9f4466f6 4887645: Remove "awt.threadgroup" system property Reviewed-by: art, anthony ! src/share/classes/sun/awt/SunToolkit.java Changeset: a0a4f73b3d1d Author: dcherepanov Date: 2010-12-27 18:42 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a0a4f73b3d1d 6957765: Test Bug - javax/swing/SwingWorker/6480289/bug6480289.java failed on 1.7.0b94 but passed on previous Reviewed-by: art, alexp - test/javax/swing/SwingWorker/6480289/bug6480289.java Changeset: 33d4e0de0424 Author: dcherepanov Date: 2010-12-27 18:43 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/33d4e0de0424 6866808: nsk/stress/jck12a/jck12a014 crashes with SIGSEGV at [libjvm.so+0xc5b10] Reviewed-by: art ! src/solaris/native/sun/xawt/XToolkit.c Changeset: c90a0da7649e Author: dcherepanov Date: 2010-12-27 18:45 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c90a0da7649e 6921598: PrinterDialog hidden behind other frames Reviewed-by: art ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Dialog.h Changeset: 39e9d5613145 Author: dav Date: 2010-12-28 17:13 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/39e9d5613145 6999766: Changes to correct c/c++ language issues for use of parfait Reviewed-by: uta, amenkov ! src/windows/native/sun/windows/Devices.h ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_Debug.cpp ! src/windows/native/sun/windows/awt_Debug.h ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_TextArea.h ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: 8b05f9b91765 Author: dav Date: 2010-12-29 15:13 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8b05f9b91765 7008106: com/sun/awt/Translucency/WindowOpacity.java test fails just against jdk7 b122 Reviewed-by: dcherepanov ! test/com/sun/awt/Translucency/WindowOpacity.java Changeset: 78364959fc73 Author: dav Date: 2010-12-29 17:36 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/78364959fc73 6963357: After clicking the "Load" button,the case FileDialogUserFilterTest.html crashes in jdk7 b98. Reviewed-by: dcherepanov ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c Changeset: aa03f76d0e80 Author: lana Date: 2011-01-05 15:54 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/aa03f76d0e80 Merge - make/common/internal/BinaryPlugs.gmk ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/sun/awt/SunToolkit.java ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: bde32b5becf1 Author: lana Date: 2011-01-06 18:01 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bde32b5becf1 Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java Changeset: ec02d02d3409 Author: okutsu Date: 2010-12-15 11:38 +0900 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ec02d02d3409 6990037: font warnings in the build, missing fonts Reviewed-by: peytoia ! make/sun/awt/Makefile ! src/share/classes/sun/awt/FontConfiguration.java Changeset: cd7b5fb40005 Author: okutsu Date: 2010-12-17 16:56 +0900 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cd7b5fb40005 7007583: (tz) Windows-only: update tzmappings for KB2443685 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: 7c7e4a0330bc Author: okutsu Date: 2010-12-17 17:13 +0900 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7c7e4a0330bc 6644493: [Fmt-Da] SimpleDateFormat parsing RFC822 time offset is slow Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java ! test/java/text/Format/DateFormat/ISO8601ZoneTest.java Changeset: f710204034fd Author: okutsu Date: 2010-12-17 18:06 +0900 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f710204034fd 6983207: API: MessageFormat quote handling discrepancy Reviewed-by: peytoia ! src/share/classes/java/text/MessageFormat.java Changeset: 89d065844fb6 Author: okutsu Date: 2010-12-21 10:58 +0900 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/89d065844fb6 6943959: NumericShaper API doc doesn't describe ARABIC/EASTERN_ARABIC precedence Reviewed-by: peytoia ! src/share/classes/java/awt/font/NumericShaper.java Changeset: 8da79c7d137e Author: okutsu Date: 2010-12-21 11:20 +0900 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8da79c7d137e 7007905: javazic produces wrong line numbers Reviewed-by: peytoia ! make/tools/src/build/tools/javazic/Zoneinfo.java Changeset: 55d9205735e1 Author: naoto Date: 2010-12-21 16:14 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/55d9205735e1 4940539: Constructor of java.util.Locale should handle ISO 639-2 Language Codes Reviewed-by: okutsu ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleTest.java Changeset: 403a88eeac15 Author: lana Date: 2010-12-22 16:57 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/403a88eeac15 Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java Changeset: c8b383fd8adf Author: rupashka Date: 2010-12-23 17:39 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c8b383fd8adf 6973773: JCK manual case JSliderTests.html#JSlider fails in jdk7 b100 Reviewed-by: alexp ! src/share/classes/javax/swing/JSlider.java Changeset: 69b2e5838eee Author: rupashka Date: 2010-12-23 18:25 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/69b2e5838eee 7007708: TEST: javax/swing/JScrollBar/6542335/bug6542335.java failes agaisnt jdk7 on solaris/linux Reviewed-by: alexp ! test/javax/swing/JScrollBar/6542335/bug6542335.java Changeset: 94e0438c74c3 Author: okutsu Date: 2010-12-27 14:13 +0900 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/94e0438c74c3 7003643: [Fmt-Me] MessageFormat.toPattern produces wrong quoted string and subformat modifiers 7008195: [Fmt-Me] Improve MessageFormat.applyPattern performance Reviewed-by: naoto, peytoia ! src/share/classes/java/text/MessageFormat.java + test/java/text/Format/MessageFormat/Bug7003643.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.sh ! test/java/util/PluggableLocale/NumberFormatProviderTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.sh ! test/java/util/PluggableLocale/fooprovider.jar ! test/java/util/PluggableLocale/providersrc/DateFormatProviderImpl.java + test/java/util/PluggableLocale/providersrc/FooDateFormat.java + test/java/util/PluggableLocale/providersrc/FooNumberFormat.java ! test/java/util/PluggableLocale/providersrc/Makefile ! test/java/util/PluggableLocale/providersrc/NumberFormatProviderImpl.java Changeset: c06d4327c0f2 Author: rupashka Date: 2010-12-27 15:28 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c06d4327c0f2 6959584: closed/javax/swing/JFileChooser/4847375/bug4847375.java : compilation failed Reviewed-by: alexp + test/javax/swing/JFileChooser/4847375/bug4847375.java Changeset: 72f1247e9ff5 Author: rupashka Date: 2010-12-27 17:41 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/72f1247e9ff5 6532833: PIT: Metal LAF - The right side border is not shown for the Spinner after the removing the buttons Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicSpinnerUI.java + test/javax/swing/JSpinner/6532833/bug6532833.java Changeset: 2c3c88a389b0 Author: amenkov Date: 2010-12-28 16:37 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2c3c88a389b0 6842956: Assertion error in javax_sound on 64-bit RHEL 5.3 with 32-bit JDK Reviewed-by: bae ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_MidiIn.c Changeset: ac1e3f99a69e Author: amenkov Date: 2010-12-29 16:26 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ac1e3f99a69e 7006997: A typo in MidiSystem.getTransmitter() implementation code Reviewed-by: dav ! src/share/classes/javax/sound/midi/MidiSystem.java Changeset: be27227ff554 Author: amenkov Date: 2010-12-30 14:57 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/be27227ff554 6989702: sound native code compiler warnings Reviewed-by: bae ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_MidiUtils.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCM.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCMUtils.h ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c Changeset: 349b67ae3e08 Author: lana Date: 2011-01-04 23:41 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/349b67ae3e08 Merge - make/common/internal/BinaryPlugs.gmk ! make/sun/awt/Makefile ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/javax/sound/midi/MidiSystem.java Changeset: fff6fd437f4a Author: lana Date: 2011-01-06 18:03 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fff6fd437f4a Merge Changeset: 6d3fb387da8e Author: ksrini Date: 2010-12-14 07:42 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6d3fb387da8e 6990106: FindBugs scan - Malicious code vulnerability Warnings in com.sun.java.util.jar.pack.* Reviewed-by: mduigou, briangoetz ! src/share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/Coding.java ! src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Histogram.java ! src/share/classes/com/sun/java/util/jar/pack/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/PopulationCoding.java ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java ! src/share/classes/java/util/jar/Pack200.java Changeset: 68cc30a3a1fd Author: ksrini Date: 2010-12-14 08:13 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/68cc30a3a1fd 7006704: (pack200) add missing file for 6990106 Reviewed-by: mduigou, briangoetz + src/share/classes/com/sun/java/util/jar/pack/FixedList.java Changeset: a72e7147816f Author: lancea Date: 2010-12-14 16:08 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a72e7147816f 7006454: Typo in javadocs typo for Statement.executeBatch @since Reviewed-by: alanb ! src/share/classes/java/sql/Statement.java Changeset: 0ef137ae6f3b Author: alanb Date: 2010-12-15 09:15 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0ef137ae6f3b 6927816: Demo crash in heaptracker with Non-Sun JDK due to possible violation of JNI spec Reviewed-by: ohair, alanb Contributed-by: spoole at uk.ibm.com ! src/share/demo/jvmti/heapTracker/heapTracker.c Changeset: e6ed7c95d94f Author: xuelei Date: 2010-12-15 22:42 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e6ed7c95d94f 7006265: Javadoc warnings Reviewed-by: weijun ! src/share/classes/javax/net/ssl/X509ExtendedTrustManager.java Changeset: e67a399dd4ad Author: sundar Date: 2010-12-16 20:52 +0530 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e67a399dd4ad 6980447: Rhino JavaScript engine code in jdk-7 has to updated with the latest code from Rhino 1.7R3. Summary: Updating Rhino javascript engine with version 1.7R3. Issue 6427783 (E4X support is missing from Sun's Mozilla JavaScript implementation) is also fixed as a side-effect. Reviewed-by: alanb, jjh ! src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java ! src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java ! src/share/classes/com/sun/script/javascript/RhinoTopLevel.java ! src/share/classes/com/sun/tools/script/shell/init.js - test/javax/script/E4XErrorTest.java ! test/javax/script/VersionTest.java Changeset: 1f0f0737f04e Author: weijun Date: 2010-12-17 11:03 +0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1f0f0737f04e 6975866: api/org_ietf/jgss/GSSContext/index.html#wrapUnwrapIOTest started to fail since jdk7 b102 Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/CipherHelper.java ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java ! src/share/classes/sun/security/jgss/krb5/MicToken_v2.java ! src/share/classes/sun/security/jgss/krb5/WrapToken.java ! src/share/classes/sun/security/jgss/krb5/WrapToken_v2.java ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/Context.java - test/sun/security/krb5/auto/basic.sh Changeset: ae84db37130a Author: ksrini Date: 2010-12-18 09:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ae84db37130a 7007157: (pack200) stripping attributes causes a NPE Reviewed-by: jrose, mduigou, dholmes ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java + test/tools/pack200/T7007157.java Changeset: 449dfb061fde Author: smarks Date: 2010-12-20 13:47 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/449dfb061fde 6880112: Project Coin: Port JDK core library code to use diamond operator Reviewed-by: darcy, lancea, alanb, briangoetz, mduigou, mchung ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/java/io/DeleteOnExitHook.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/lang/ApplicationShutdownHooks.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/CharacterName.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/StringCoding.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/Throwable.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/lang/reflect/ReflectAccess.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/EnumMap.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/HashSet.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/JumboEnumSet.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/ListResourceBundle.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/RegularEnumSet.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/TimSort.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/prefs/AbstractPreferences.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/sun/io/Converters.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! src/solaris/classes/java/lang/ProcessEnvironment.java ! src/solaris/classes/java/util/prefs/FileSystemPreferences.java ! src/windows/classes/java/lang/ProcessEnvironment.java ! test/java/io/Serializable/NPEProvoker/NPEProvoker.java ! test/java/lang/instrument/ilib/Inject.java ! test/java/lang/instrument/ilib/InjectBytecodes.java ! test/java/lang/reflect/Generics/TestPlainArrayNotGeneric.java ! test/java/util/Random/DistinctSeeds.java ! test/java/util/logging/ClassLoaderLeakTest.java Changeset: d2a0e795c1c2 Author: weijun Date: 2010-12-21 17:35 +0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d2a0e795c1c2 6996367: improve HandshakeHash Reviewed-by: xuelei ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java Changeset: d36ad8686f6d Author: kevinw Date: 2010-12-21 11:32 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d36ad8686f6d 6968933: Clip loop() deadlock in DirectAudioDevice$DirectClip.run Reviewed-by: amenkov ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java Changeset: 9deace8396f9 Author: ptisnovs Date: 2010-12-22 14:37 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9deace8396f9 6560348: PIT : java/awt/xembed/server/RunTestXEmbed.java fails Summary: Testcase correction. Reviewed-by: anthony ! test/java/awt/xembed/server/TestXEmbedServer.java Changeset: 0d826185a92e Author: xuelei Date: 2010-12-22 06:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0d826185a92e 6996365: Evaluate the priorities of cipher suites Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/CipherSuite.java Changeset: d4c2d2d72cfc Author: valeriep Date: 2010-12-22 18:30 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d4c2d2d72cfc 6581254: pkcs11 provider fails to parse configuration file contains windows short path Summary: Modified configuration parsing code to support "~". Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/Config.java + test/sun/security/pkcs11/Provider/ConfigShortPath.java + test/sun/security/pkcs11/Provider/csp.cfg Changeset: 6acd81baf2c7 Author: lana Date: 2010-12-22 23:12 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6acd81baf2c7 Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/util/ListResourceBundle.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java Changeset: 5beec82bf20d Author: ksrini Date: 2010-12-23 13:51 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5beec82bf20d 7002386: (launcher) fix XshowSettings Reviewed-by: darcy, mchung, naoto ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java ! test/tools/launcher/Settings.java Changeset: 3c4afaacd345 Author: dcubed Date: 2010-12-23 23:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3c4afaacd345 7005984: 3/3 Incorrect values of S0C and S0CMX appear with -gcnewcapacity in jstat Summary: Swap S0C and S0CMX column values. Reviewed-by: ohair, dholmes, poonam ! src/share/classes/sun/tools/jstat/resources/jstat_options ! test/sun/tools/jstat/gcNewCapacityOutput1.awk Changeset: adff75ebdc00 Author: valeriep Date: 2010-12-22 19:19 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/adff75ebdc00 6924489: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_OPERATION_NOT_INITIALIZED Summary: Reset cipher state to un-initialized wherever necessary. Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/P11Cipher.java Changeset: 3254c3ae63fe Author: valeriep Date: 2010-12-27 11:39 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3254c3ae63fe Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java Changeset: 6f2d19ef67b1 Author: alanb Date: 2011-01-04 17:49 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6f2d19ef67b1 7010192: InetAddress.isReachable hits ShouldNotReachHere with hs20-b04 (win) Reviewed-by: chegar ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c Changeset: 4379c762ec50 Author: sherman Date: 2011-01-04 14:17 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4379c762ec50 7009618: regression test failed caused by the fix for 7003462 Summary: avoid caching the "ended" Inflater in ZipFile class Reviewed-by: alanb ! src/share/classes/java/util/zip/Inflater.java ! src/share/classes/java/util/zip/ZipFile.java + test/java/util/zip/ZipFile/FinalizeZipFile.java Changeset: 58aa8eadae5f Author: lana Date: 2011-01-04 17:05 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/58aa8eadae5f Merge - make/common/internal/BinaryPlugs.gmk ! src/share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/Coding.java ! src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Histogram.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.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/PopulationCoding.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/ListResourceBundle.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/sun/io/Converters.java ! src/share/classes/sun/tools/jstat/resources/jstat_options ! src/share/classes/sun/util/logging/PlatformLogger.java ! test/sun/security/krb5/auto/Context.java Changeset: d56c111ec6dc Author: jjg Date: 2011-01-06 14:32 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d56c111ec6dc 7010537: javah no longer depends on javadoc Reviewed-by: ohair ! make/common/shared/Defs-java.gmk Changeset: c4ec4f80f44e Author: lana Date: 2011-01-06 18:05 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c4ec4f80f44e Merge - test/javax/script/E4XErrorTest.java - test/sun/security/krb5/auto/basic.sh Changeset: 1513e13fae08 Author: lana Date: 2011-01-13 15:03 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1513e13fae08 Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/security/krb5/auto/basic.sh Changeset: 8361ef97a0f9 Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8361ef97a0f9 Merge Changeset: 29e09de1d0b4 Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/29e09de1d0b4 Added tag jdk7-b126 for changeset 8361ef97a0f9 ! .hgtags Changeset: 66c86ca4079a Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/66c86ca4079a Added tag jdk7-b127 for changeset 29e09de1d0b4 ! .hgtags Changeset: 63f5c7704faa Author: prr Date: 2011-01-12 15:58 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/63f5c7704faa 6958221: java.awt.Font.getFamily() leads to JVM crash on Linux on JDK7 for "custom" fonts Reviewed-by: igor, jgodinez ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/headless/mapfile-vers ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11FontManager.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/native/sun/awt/fontpath.c + test/java/awt/FontClass/X11FontPathCrashTest.java Changeset: 5aae8b3162d0 Author: prr Date: 2011-01-13 10:36 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5aae8b3162d0 7001056: JDK 7 fails on to build on Solaris 10 update 9 - updated Xrender header files Reviewed-by: igor, jgodinez ! make/sun/xawt/Makefile ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 76b8fa7fd229 Author: prr Date: 2011-01-13 12:08 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/76b8fa7fd229 7012269: mapfile for headless awt needs getFontPathNative defined Reviewed-by: igor ! make/sun/headless/mapfile-vers Changeset: 9f3f38c150b5 Author: prr Date: 2011-01-13 14:11 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9f3f38c150b5 6917884: NPE in sun.font.FcFontConfiguration.getPlatformFontNames Reviewed-by: igor, jgodinez ! src/solaris/classes/sun/font/FontConfigManager.java Changeset: 987aeabbfda3 Author: prr Date: 2011-01-14 11:05 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/987aeabbfda3 6951086: Excessive Local References in sun.font.SunLayoutEngine.nativeLayout Reviewed-by: igor, jgodinez ! src/share/native/sun/font/FontInstanceAdapter.cpp Changeset: 646c3cf1ba37 Author: prr Date: 2011-01-14 11:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/646c3cf1ba37 6989370: Windows platform fonts may be incorrectly marked as ineligible for the native rasteriser Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/SunFontManager.java ! src/windows/classes/sun/awt/Win32FontManager.java Changeset: 5cb6bb816a34 Author: prr Date: 2011-01-14 12:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5cb6bb816a34 6925760: Scaled graphics can cause overlapped LCD mode strings on Windows for pixel size > 48 Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FileFontStrike.java + test/java/awt/FontClass/LCDScale.java Changeset: 8b33567d68b0 Author: jgodinez Date: 2011-01-14 14:25 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8b33567d68b0 6939417: ArrayIndexOutOfBoundsException in Win 7 on selected printers Reviewed-by: igor, prr ! src/windows/classes/sun/print/Win32PrintService.java ! test/javax/print/DialogMargins.java Changeset: c2fcb5530ba5 Author: prr Date: 2011-01-14 15:07 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c2fcb5530ba5 6930980: Disable TrueType hinting for fonts known not to hint well Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/NullFontScaler.java Changeset: 0bec5d506120 Author: dlila Date: 2011-01-19 09:44 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0bec5d506120 4724552: CubicCurve2D.contains(Rectangle2D) returns true when only partially contained. Summary: Now using subdivision code in sun.awt.geom.Curve. Reviewed-by: flar ! src/share/classes/java/awt/geom/CubicCurve2D.java Changeset: c8a10bfd2fcb Author: dlila Date: 2011-01-19 11:31 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c8a10bfd2fcb 4493128: CubicCurve2D intersects method fails Summary: Now using subdivision code in sun.awt.geom.Curve. Reviewed-by: flar ! src/share/classes/java/awt/geom/CubicCurve2D.java Changeset: 00cc1c09c6dd Author: prr Date: 2011-01-19 09:22 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/00cc1c09c6dd 6951501: EUDC character is not displayed on Swing Reviewed-by: igor, jgodinez ! src/windows/classes/sun/awt/Win32FontManager.java ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp Changeset: e58e9e32399a Author: prr Date: 2011-01-19 17:02 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e58e9e32399a 6983037: closed/java/awt/font/FontNames/Type1Fonts.java failed due to missed font Reviewed-by: igor ! src/share/classes/sun/font/SunFontManager.java ! src/solaris/classes/sun/awt/X11FontManager.java Changeset: fe1b5c15afab Author: prr Date: 2011-01-19 17:07 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fe1b5c15afab 7013109: windows application manifest problems 6820955: Update application manifests with new Windows 7 dpiAware section Reviewed-by: ohair, art ! make/common/Defs-windows.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! src/windows/resource/java.manifest Changeset: aa1825b1b69d Author: lana Date: 2011-01-19 19:35 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/aa1825b1b69d Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/security/krb5/auto/basic.sh Changeset: 0044e8e16a30 Author: prr Date: 2011-01-20 10:45 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0044e8e16a30 6980204: closed/java/awt/font/LogicalFonts/MappingTest.java fails Reviewed-by: jgodinez ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java Changeset: b1c41e0321a2 Author: prr Date: 2011-01-20 13:56 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b1c41e0321a2 7013646: remove obsolete fontconfig files for linux and solaris Reviewed-by: igor, jgodinez ! make/sun/awt/Makefile - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java ! src/solaris/classes/sun/font/FcFontConfiguration.java Changeset: b8f08482aca1 Author: prr Date: 2011-01-21 07:59 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b8f08482aca1 6892493: potential memory leaks in 2D font code indentified by parfait. Reviewed-by: bae, igor ! src/solaris/native/sun/awt/fontpath.c Changeset: c17e5a95aba7 Author: prr Date: 2011-01-21 08:04 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c17e5a95aba7 6892138: Windows GDI platform font lookup apis affect start-up for small UI apps Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/SunFontManager.java ! src/windows/classes/sun/awt/Win32FontManager.java + test/java/awt/font/FontNames/LocaleFamilyNames.java Changeset: ade796b84e71 Author: bae Date: 2011-01-24 15:14 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ade796b84e71 7002766: Java2d: Changes to correct c/c++ language issues for use of parfait Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/image/jpeg/jmorecfg.h ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: 63a2e8e00a7b Author: bae Date: 2011-01-24 15:37 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/63a2e8e00a7b 6999620: [parfait] potential buffer overruns in 2d and awt Reviewed-by: jgodinez, prr ! src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 74d020ed7f5b Author: lana Date: 2011-01-24 13:18 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/74d020ed7f5b Merge - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties Changeset: 5d4723944cbd Author: dcherepanov Date: 2011-01-20 14:27 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5d4723944cbd 7011446: ./windows/classes/sun/awt/windows/WToolkit.java needs to avoid spurious wakeup Reviewed-by: anthony ! src/windows/classes/sun/awt/windows/WToolkit.java Changeset: 1bb32dc775c8 Author: dcherepanov Date: 2011-01-20 14:28 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1bb32dc775c8 7011443: ./share/classes/sun/awt/SunToolkit.java needs to avoid spurious wakeup Reviewed-by: anthony ! src/share/classes/sun/awt/SunToolkit.java Changeset: 4cd8718d4548 Author: dcherepanov Date: 2011-01-20 14:29 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4cd8718d4548 7011442: AppletClassLoader.java needs to avoid spurious wakeup Reviewed-by: anthony ! src/share/classes/sun/applet/AppletClassLoader.java Changeset: 4c9a9871830f Author: lana Date: 2011-01-20 10:49 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4c9a9871830f Merge - test/javax/script/E4XErrorTest.java - test/sun/security/krb5/auto/basic.sh Changeset: f6b73a9b3895 Author: lana Date: 2011-01-24 13:20 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f6b73a9b3895 Merge Changeset: 63972a313ca4 Author: rupashka Date: 2011-01-11 12:51 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/63972a313ca4 6589952: Swing: dead links in API documentation Reviewed-by: alexp ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/SizeSequence.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/event/InternalFrameAdapter.java ! src/share/classes/javax/swing/event/InternalFrameListener.java ! src/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html ! src/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/ParagraphView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java Changeset: 2a966dd275fc Author: rupashka Date: 2011-01-13 20:12 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2a966dd275fc 6990651: Regression: NPE when refreshing applet since 6u22-b01 Reviewed-by: peterz ! src/share/classes/javax/swing/text/html/parser/ParserDelegator.java + test/javax/swing/JLabel/7004134/bug7004134.java + test/javax/swing/text/html/parser/Parser/6990651/bug6990651.java Changeset: 5787add5b679 Author: rupashka Date: 2011-01-17 19:14 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5787add5b679 6342301: Bad interaction between setting the ui and file filters in JFileChooser Reviewed-by: alexp ! src/share/classes/javax/swing/JFileChooser.java + test/javax/swing/JFileChooser/6342301/bug6342301.java Changeset: ca3bafeffd3b Author: rupashka Date: 2011-01-19 17:01 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ca3bafeffd3b 6246816: SwingSet2 should be rewritten Reviewed-by: peterz ! make/common/Demo.gmk ! make/mkdemo/jfc/Makefile + make/mkdemo/jfc/SwingSet3/Makefile Changeset: e93106dc798b Author: lana Date: 2011-01-19 21:51 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e93106dc798b Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/security/krb5/auto/basic.sh Changeset: b45ea2c3bd6d Author: rupashka Date: 2011-01-24 18:04 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b45ea2c3bd6d 6735293: javax.swing.text.NavigationFilter.getNextVisualPositionFrom() not always throws BadLocationException Reviewed-by: peterz ! src/share/classes/javax/swing/text/View.java + test/javax/swing/text/NavigationFilter/6735293/bug6735293.java Changeset: 1f3ecbfa0c29 Author: lana Date: 2011-01-24 13:21 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1f3ecbfa0c29 Merge Changeset: b8663921f5d7 Author: chegar Date: 2011-01-07 13:08 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b8663921f5d7 7000511: PrintStream, PrintWriter, Formatter, Scanner leave files open when exception thrown Reviewed-by: alanb, mduigou ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Scanner.java ! test/ProblemList.txt + test/java/io/PrintStream/FailingConstructors.java + test/java/io/PrintWriter/FailingConstructors.java ! test/java/util/Formatter/Constructors.java + test/java/util/Formatter/FailingConstructors.java + test/java/util/Scanner/FailingConstructors.java Changeset: 5124c2a50539 Author: alanb Date: 2011-01-07 15:49 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5124c2a50539 6993732: Remove the HPI Reviewed-by: ohair, lancea, chegar, mduigou, mchung, mr ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Defs.gmk ! make/common/Modules.gmk ! make/common/Release.gmk ! make/java/Makefile ! make/java/fdlibm/Makefile - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile ! make/tools/reorder/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c Changeset: ddaffd64796c Author: alanb Date: 2011-01-07 15:51 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ddaffd64796c Merge Changeset: 6bf1c5958c22 Author: chegar Date: 2011-01-07 21:02 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6bf1c5958c22 7009760: Possible stack corruption in Java_java_net_TwoStacksPlainSocketImpl_socketGetOption Summary: SOCKET_ADDRESS -> SOCKETADDRESS Reviewed-by: alanb ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c Changeset: 3dbc783a8073 Author: smarks Date: 2011-01-07 15:39 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3dbc783a8073 7008728: diamond conversion of basic security, permissions, authentication Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/SolarisLoginModule.java ! src/share/classes/com/sun/security/auth/module/UnixLoginModule.java ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/CodeSource.java ! src/share/classes/java/security/Permissions.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/SecureClassLoader.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/UnresolvedPermission.java ! src/share/classes/java/security/UnresolvedPermissionCollection.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/sun/security/acl/AclEntryImpl.java ! src/share/classes/sun/security/acl/AclImpl.java ! src/share/classes/sun/security/acl/GroupImpl.java ! test/com/sun/security/auth/module/LdapLoginModule/CheckConfigs.java ! test/com/sun/security/auth/module/LdapLoginModule/CheckOptions.java Changeset: ee5bf287d0c4 Author: alanb Date: 2011-01-10 09:32 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ee5bf287d0c4 7002957: (fc) FileChannel.transferTo fails to load libsendfile on Solaris 64-bit Reviewed-by: chegar ! make/java/nio/Makefile ! src/solaris/native/sun/nio/ch/FileChannelImpl.c Changeset: f4d755bbdabe Author: lancea Date: 2011-01-10 14:43 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f4d755bbdabe 6544224: Remove the need of sun.reflect.misc Reviewed-by: alanb ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java Changeset: 2a0ff59928de Author: smarks Date: 2011-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2a0ff59928de 7005608: diamond conversion of JCA and crypto providers Reviewed-by: wetmore ! src/share/classes/java/security/Security.java ! src/share/classes/sun/security/jca/ProviderList.java ! src/share/classes/sun/security/jca/Providers.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/provider/VerificationProvider.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/rsa/RSACore.java ! src/share/classes/sun/security/rsa/SunRsaSign.java Changeset: befe813e24d2 Author: lancea Date: 2011-01-11 12:36 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/befe813e24d2 7000693: java.sql.Timestamp compareTo() issues using low values Reviewed-by: okutsu ! src/share/classes/java/sql/Timestamp.java Changeset: 6d0217114886 Author: smarks Date: 2011-01-11 13:42 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6d0217114886 7011095: revert diamond changes from 6880112 that occur in method args Reviewed-by: darcy, alanb ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/lang/StringCoding.java ! src/share/classes/java/util/logging/Logger.java Changeset: cb3ecb5e4ce5 Author: dl Date: 2011-01-12 14:40 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cb3ecb5e4ce5 7005424: Resync java.util.concurrent classes with Dougs CVS - Jan 2011 Reviewed-by: dholmes, chegar, mduigou ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicMarkableReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java ! src/share/classes/java/util/concurrent/locks/Condition.java ! test/ProblemList.txt ! test/java/util/WeakHashMap/GCDuringIteration.java ! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java ! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java ! test/java/util/concurrent/Executors/AutoShutdown.java ! test/java/util/concurrent/Phaser/Basic.java + test/java/util/concurrent/Phaser/FickleRegister.java + test/java/util/concurrent/Phaser/PhaseOverflow.java + test/java/util/concurrent/Phaser/TieredArriveLoops.java ! test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java Changeset: a5a22f93e4c5 Author: smarks Date: 2011-01-12 13:52 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a5a22f93e4c5 7008713: diamond conversion of kerberos5 and security tools Reviewed-by: weijun ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/Authenticator.java ! src/share/classes/sun/security/krb5/internal/AuthorizationData.java ! src/share/classes/sun/security/krb5/internal/EncAPRepPart.java ! src/share/classes/sun/security/krb5/internal/HostAddresses.java ! src/share/classes/sun/security/krb5/internal/KDCReq.java ! src/share/classes/sun/security/krb5/internal/KDCReqBody.java ! src/share/classes/sun/security/krb5/internal/KRBCred.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java ! src/share/classes/sun/security/krb5/internal/LastReq.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! test/sun/security/krb5/IPv6.java ! test/sun/security/krb5/auto/CleanState.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/LoginModuleOptions.java ! test/sun/security/krb5/tools/KtabCheck.java Changeset: f5c0b3cbee2f Author: kamg Date: 2011-01-12 11:47 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f5c0b3cbee2f 6436034: Instance filter doesn't filter event if it occurs in native method Summary: Use 'GetLocalInstance' JVMTI extension if it exists Reviewed-by: coleenp, dcubed ! src/share/back/debugInit.c ! src/share/back/eventFilter.c ! src/share/instrument/JPLISAgent.c ! src/share/javavm/export/jvmti.h + test/com/sun/jdi/NativeInstanceFilter.java + test/com/sun/jdi/NativeInstanceFilterTarg.java Changeset: 295f6b861c12 Author: kamg Date: 2011-01-12 15:27 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/295f6b861c12 Merge Changeset: 538f913777cf Author: michaelm Date: 2011-01-13 11:01 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/538f913777cf 6896088: URLClassLoader.close() apparently not working for JAR URLs on Windows Reviewed-by: chegar ! src/share/classes/sun/misc/URLClassPath.java + test/java/net/URLClassLoader/B6896088.java Changeset: 9f265d55c1c4 Author: michaelm Date: 2011-01-13 11:02 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9f265d55c1c4 Merge Changeset: 694951adefec Author: chegar Date: 2011-01-13 13:24 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/694951adefec 6964547: Impossible to set useV4 in SocksSocketImpl Summary: Add socksProxyVersion property Reviewed-by: alanb, michaelm ! make/sun/net/FILES_java.gmk ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/doc-files/net-properties.html + src/share/classes/sun/net/SocksProxy.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java + test/java/net/Socks/SocksProxyVersion.java Changeset: 38729ba6eb4f Author: michaelm Date: 2011-01-12 15:05 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/38729ba6eb4f 6829919: URLClassLoader.close() doesn't close resource file if getResourceAsStream(...) was called before Reviewed-by: chegar ! src/share/classes/java/net/URLClassLoader.java ! test/java/net/URLClassLoader/closetest/CloseTest.java + test/java/net/URLClassLoader/closetest/Common.java + test/java/net/URLClassLoader/closetest/GetResourceAsStream.java + test/java/net/URLClassLoader/closetest/build2.sh Changeset: ed390b2e5ca4 Author: michaelm Date: 2011-01-13 11:10 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ed390b2e5ca4 Merge Changeset: 067b5f603fc8 Author: michaelm Date: 2011-01-13 14:41 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/067b5f603fc8 Merge Changeset: 3215b22cd90e Author: michaelm Date: 2011-01-13 16:33 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3215b22cd90e 7003398: NetworkInterface equals() and hashCode() behaviors depend on permissions granted Reviewed-by: chegar, alanb ! src/share/classes/java/net/NetworkInterface.java + test/java/net/NetworkInterface/Equals.java Changeset: 29f2e311cce7 Author: mduigou Date: 2011-01-13 20:32 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/29f2e311cce7 6728865: Provide a better heuristics for Collections.disjoint method Reviewed-by: alanb, dholmes, chegar, forax ! src/share/classes/java/util/Collections.java Changeset: 59e352561146 Author: darcy Date: 2011-01-13 22:21 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/59e352561146 7012279: Project Coin: Clarify AutoCloseable and Throwable javadoc Reviewed-by: jjb ! src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Throwable.java Changeset: 983364897f72 Author: chegar Date: 2011-01-14 22:34 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/983364897f72 7010903: impl. of http.maxConnections is different from the description in JavaSE document Reviewed-by: alanb, michaelm ! src/share/classes/sun/net/www/http/KeepAliveCache.java Changeset: d61d9bf190f5 Author: smarks Date: 2011-01-14 15:31 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d61d9bf190f5 7012003: diamond conversion for ssl Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHandlerTest.java Changeset: 507627325c81 Author: sundar Date: 2011-01-17 13:29 +0530 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/507627325c81 6508943: small typo in the documentation 6759414: javascript engine can not write to StringWriter 6869617: RhinoScriptEngine bug : ScriptException cause not set (with fix) 7012701: Add a test to check that Rhino's RegExp parser accepts unescaped '[' Reviewed-by: alanb, jjh ! src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java ! src/share/classes/javax/script/CompiledScript.java + test/javax/script/CauseExceptionTest.java + test/javax/script/StringWriterPrintTest.java + test/javax/script/UnescapedBracketRegExTest.java Changeset: 9596a600758c Author: lana Date: 2011-01-19 19:00 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9596a600758c Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java Changeset: e64b1f11cd0b Author: chegar Date: 2011-01-20 15:23 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e64b1f11cd0b 7011857: java/util/concurrent/Phaser/FickleRegister.java fails on solaris-sparc Summary: Remove from ProblemList, failure resolved by 7009231 Reviewed-by: alanb ! test/ProblemList.txt Changeset: cc195c981ae2 Author: mchung Date: 2011-01-20 22:17 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cc195c981ae2 7013739: jdk_rmi target is missing in the top repo's test/Makefile Reviewed-by: ohair, igor ! test/ProblemList.txt Changeset: 2a8d1a0a2418 Author: chegar Date: 2011-01-21 17:02 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2a8d1a0a2418 7012768: InetAddress lookupTable leaks/deadlocks when using unsupported name service spi Reviewed-by: alanb, michaelm ! src/share/classes/java/net/InetAddress.java - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/chaining/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/net/InetAddress/nameservice/chaining/Providers.java + test/sun/net/InetAddress/nameservice/chaining/Simple1NameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/chaining/Simple2NameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/chaining/SimpleNameService.java + test/sun/net/InetAddress/nameservice/deadlock/Hang.java + test/sun/net/InetAddress/nameservice/deadlock/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/net/InetAddress/nameservice/deadlock/ThrowingNameService.java + test/sun/net/InetAddress/nameservice/deadlock/ThrowingNameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/simple/CacheTest.java + test/sun/net/InetAddress/nameservice/simple/DefaultCaching.java + test/sun/net/InetAddress/nameservice/simple/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/net/InetAddress/nameservice/simple/SimpleNameService.java + test/sun/net/InetAddress/nameservice/simple/SimpleNameServiceDescriptor.java Changeset: 6a7b8406a1b9 Author: chegar Date: 2011-01-21 17:04 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6a7b8406a1b9 Merge Changeset: f26d1a7fe4d2 Author: mchung Date: 2011-01-21 09:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f26d1a7fe4d2 6912013: Remove the temporary launcher fix to add modules in the bootclasspath Reviewed-by: ksrini ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/classes/sun/launcher/LauncherHelper.java Changeset: 9c18818e7a5f Author: mchung Date: 2011-01-21 09:45 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9c18818e7a5f Merge - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 2381e810330b Author: zgu Date: 2011-01-20 10:45 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2381e810330b 6983248: net/net001 and net/net003 fail on WinXP with JDK7-B108 Summary: Using closesocket to close socket handler to avoid invalid C runtime parameter exception. Reviewed-by: alanb, phh, dcubed, dsamersoff, coleenp, acorn ! src/windows/demo/jvmti/hprof/hprof_md.c Changeset: d03e47de3a89 Author: zgu Date: 2011-01-21 11:38 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d03e47de3a89 Merge Changeset: c73c178159d8 Author: phh Date: 2011-01-20 19:34 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c73c178159d8 6173675: M&M: approximate memory allocation rate/amount per thread Summary: Subclass com.sun.management.ThreadMXBean from java.lang.management.ThreadMXBean, add getAllocatedBytes() and friends to c.s.m.ThreadMXBean and have sun.management.ThreadImpl implement c.s.m.ThreadMXBean rather than j.l.m.ThreadMXBean. Reviewed-by: mchung, alanb, dholmes, emcmanus ! make/java/management/mapfile-vers + src/share/classes/com/sun/management/ThreadMXBean.java ! src/share/classes/sun/management/ThreadImpl.java ! src/share/classes/sun/management/VMManagement.java ! src/share/classes/sun/management/VMManagementImpl.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/ThreadImpl.c ! src/share/native/sun/management/VMManagementImpl.c + test/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java + test/com/sun/management/ThreadMXBean/ThreadAllocatedMemoryArray.java + test/com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java Changeset: 64ef2f52d781 Author: phh Date: 2011-01-21 07:29 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/64ef2f52d781 7013682: two test checking cpuTime filed java/lang/management/ThreadMXBean Summary: Typo in 6173675 fix dropped getThreadCpuTime(long) result on the floor. Reviewed-by: mchung, dholmes ! src/share/classes/sun/management/ThreadImpl.java Changeset: cd13b2114f2e Author: phh Date: 2011-01-22 08:42 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cd13b2114f2e Merge ! src/share/classes/sun/management/ThreadImpl.java Changeset: d1365fdfb3ea Author: phh Date: 2011-01-22 08:43 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d1365fdfb3ea Merge - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 4cc447291326 Author: sherman Date: 2011-01-24 11:47 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4cc447291326 7006576: (zipfs) Path.exists() always returns false on dirs when zip/JAR file built without dirs 7009092: (zipfs) ZipPath.isSameFile() should always return true if this Path and the given Path are equal. 7009085: (zipfs) ZipPath.normalize("/./.") returns null. 7009102: (zipfs) ZipPath.toRealPath() should always return absolute path. Summary: zip filesystem provider update Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java ! test/demo/zipfs/PathOps.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: 1f977c82b733 Author: lana Date: 2011-01-24 13:24 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1f977c82b733 Merge ! make/common/Defs-windows.gmk - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 47cfd89c3227 Author: lana Date: 2011-01-28 10:04 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/47cfd89c3227 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 006c683ead1a Author: ohair Date: 2011-01-05 14:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/006c683ead1a 6975326: Problem in install/make/rebase/Makefile, grep on empty pattern 6413588: Add 'ldd -r' and 'dump -Lv' checks to all .so files delivered in the JDK 7000995: Add check in makefiles to verify that msvcp100.dll is NOT used Reviewed-by: mduigou ! make/com/sun/java/pack/Makefile ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/java/redist/Makefile Changeset: 9576644931b2 Author: ohair Date: 2011-01-07 21:52 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9576644931b2 6980024: Rebranding jre7/jdk7 License, Copyright, Readme 6912291: Third party license agreement should be present in all bundles Reviewed-by: katleman ! make/common/Modules.gmk ! make/common/Release.gmk ! make/common/shared/Defs-control.gmk Changeset: 8c3c6ac6fcdb Author: ohair Date: 2011-01-10 09:59 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8c3c6ac6fcdb Merge Changeset: 658559ca4526 Author: ohair Date: 2011-01-10 17:00 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/658559ca4526 7011382: Fix use of VS100COMNTOOLS when installed in non-default or non-space path Reviewed-by: prr ! make/common/shared/Defs-windows.gmk Changeset: fd6319676bd3 Author: ohair Date: 2011-01-10 17:53 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fd6319676bd3 Merge Changeset: 713d20f796c0 Author: ohair Date: 2011-01-10 18:07 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/713d20f796c0 6989472: Provide simple jdk identification information in the install image Reviewed-by: alanb ! make/common/Release.gmk ! make/common/shared/Defs-versions.gmk Changeset: 523386cfb731 Author: ohair Date: 2011-01-10 22:26 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/523386cfb731 Merge Changeset: 83cef4633684 Author: ohair Date: 2011-01-13 17:51 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/83cef4633684 Merge Changeset: 4241588a12c3 Author: ohair Date: 2011-01-13 13:49 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4241588a12c3 7008047: remove sanity check of msival tool from JDK tree Reviewed-by: billyh ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk Changeset: 81e66ce6f501 Author: ohair Date: 2011-01-13 23:58 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/81e66ce6f501 Merge Changeset: 0c29bbd10e19 Author: ohair Date: 2011-01-14 14:04 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0c29bbd10e19 6950375: Remove msvcrt.dll from the Windows JRE bundles Reviewed-by: prr ! make/Makefile ! make/common/Defs-windows.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/java/redist/Makefile ! make/jdk_generic_profile.sh ! src/share/demo/jvmti/index.html Changeset: 329f49ab5c4c Author: ohair Date: 2011-01-16 12:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/329f49ab5c4c Merge Changeset: 688f415db098 Author: ohair Date: 2011-01-26 16:05 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/688f415db098 Merge Changeset: aecb8f0eb83b Author: ohair Date: 2011-01-27 18:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/aecb8f0eb83b Merge Changeset: f08682e23279 Author: ohair Date: 2011-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f08682e23279 Merge ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Modules.gmk ! make/common/Program.gmk ! make/common/Release.gmk Changeset: 07c68a15ec79 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/07c68a15ec79 Added tag jdk7-b128 for changeset f08682e23279 ! .hgtags Changeset: 001dcfd0be4b Author: ohair Date: 2011-02-08 16:30 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/001dcfd0be4b 7016976: Documentation for required ant version on JDK7 builds on Solaris 10 and Solaris 11 Reviewed-by: rinaldo ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity.gmk Changeset: 1f056ddda771 Author: ohair Date: 2011-01-28 14:32 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1f056ddda771 7014301: Change make 3.81 sanity check to a fatal, 3.81 is needed now Reviewed-by: alanb ! make/common/shared/Sanity.gmk Changeset: 3f77dae85c85 Author: ohair Date: 2011-02-08 13:06 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3f77dae85c85 Merge Changeset: 14cd5d54a8d0 Author: ohair Date: 2011-02-08 20:00 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/14cd5d54a8d0 Merge ! make/common/shared/Sanity.gmk Changeset: 326aac19a89f Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/326aac19a89f Added tag jdk7-b129 for changeset 14cd5d54a8d0 ! .hgtags Changeset: bad0ddc6f573 Author: prr Date: 2011-01-26 11:46 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bad0ddc6f573 7014738: Update jdk repo application manifests with Windows 7 compatibility section. Reviewed-by: bae, igor ! src/windows/resource/java.manifest Changeset: d0e158473b6f Author: prr Date: 2011-01-26 13:26 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d0e158473b6f 6940890: Java doesn't pick up the correct fontconfig files in latest Solaris Next builds Reviewed-by: bae, igor ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java Changeset: 4cf20706dbfa Author: dlila Date: 2011-01-27 16:43 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4cf20706dbfa 4645692: solveCubic does not return all solutions. Summary: more robust solveCubic implementation. Reviewed-by: flar ! src/share/classes/java/awt/geom/CubicCurve2D.java + test/java/awt/geom/CubicCurve2D/ContainsTest.java + test/java/awt/geom/CubicCurve2D/IntersectsTest.java + test/java/awt/geom/CubicCurve2D/SolveCubicTest.java Changeset: 21621a756b32 Author: lana Date: 2011-02-03 19:15 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/21621a756b32 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 5e624003e622 Author: dlila Date: 2011-02-08 09:22 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5e624003e622 7016856: dashing performance was reduced during latest changes to the OpenJDK rasterizer Summary: Optimized dashing, rasterizing, and the flow of transformed coordinates Reviewed-by: flar ! src/share/classes/sun/java2d/pisces/Curve.java ! src/share/classes/sun/java2d/pisces/Dasher.java ! src/share/classes/sun/java2d/pisces/Helpers.java ! src/share/classes/sun/java2d/pisces/PiscesCache.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java ! src/share/classes/sun/java2d/pisces/Renderer.java ! src/share/classes/sun/java2d/pisces/Stroker.java ! src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java Changeset: 577c5d930e44 Author: dav Date: 2011-01-25 15:33 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/577c5d930e44 6693961: cross-window focus transfer ability in the Focus Spec should be revised Reviewed-by: ant, art ! src/share/classes/java/awt/doc-files/FocusSpec.html Changeset: 5f3615691623 Author: dav Date: 2011-01-25 19:07 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5f3615691623 6431076: Cursor gets reset to text cursor in xawt TextArea when autoscrolling on append Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XGlobalCursorManager.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java + test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test.java + test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test1.java Changeset: 6fd2d28e66cd Author: denis Date: 2011-01-28 16:52 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6fd2d28e66cd 6340263: Regression testcase java/awt/dnd/DnDClipboardDeadlockTest throughs IOException: Owner timed out Reviewed-by: anthony, art ! src/solaris/classes/sun/awt/X11/XSelection.java Changeset: 9da15efec22b Author: andrew Date: 2011-02-01 17:44 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9da15efec22b 7015232: missing copyright header in CheckZOrderChange.java Summary: Add standard GPL header as on other tests Reviewed-by: anthony ! test/java/awt/Container/CheckZOrderChange/CheckZOrderChange.java Changeset: 3244848a4a2b Author: dav Date: 2011-02-04 17:32 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3244848a4a2b 6741526: KeyboardFocusManager.setDefaultFocusTraversalPolicy(FocusTraversalPolicy) affects created components Reviewed-by: ant, dcherepanov ! src/share/classes/java/awt/Window.java + test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_AWT.java + test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java Changeset: b5fc02e1a944 Author: lana Date: 2011-02-08 14:19 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b5fc02e1a944 Merge Changeset: 69fac04eda38 Author: rupashka Date: 2011-01-27 14:23 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/69fac04eda38 6902615: Method JTextComponent.getKeyStrokesForAction() throws StackOverflowError Reviewed-by: peterz ! src/share/classes/javax/swing/text/Keymap.java Changeset: ec066e903b84 Author: rupashka Date: 2011-01-27 14:33 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ec066e903b84 6935155: @since tag is missing in JTextComponent.save/restoreComposedText Reviewed-by: alexp ! src/share/classes/javax/swing/text/JTextComponent.java Changeset: 457f6b2cc155 Author: malenkov Date: 2011-01-31 21:22 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/457f6b2cc155 7001484: DOC: Method javax.swing.border.StrokeBorder.getBorderInsets() should specify how it converts float Reviewed-by: alexp ! src/share/classes/javax/swing/border/StrokeBorder.java Changeset: 020b4695370c Author: malenkov Date: 2011-01-31 21:31 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/020b4695370c 7001118: DOC: javax.swing.border.StrokeBorder.paintBorder() doesn't throw NPE in all specified cases Reviewed-by: alexp ! src/share/classes/javax/swing/border/StrokeBorder.java Changeset: 07bea0d4e454 Author: malenkov Date: 2011-01-31 21:49 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/07bea0d4e454 6999045: DOC: Unclear spec for BevelBorder constructor and BorderFactory factory method (colors switching) Reviewed-by: alexp ! src/share/classes/javax/swing/BorderFactory.java ! src/share/classes/javax/swing/border/BevelBorder.java Changeset: cbcd461067c5 Author: rupashka Date: 2011-02-02 18:37 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cbcd461067c5 6988168: Press the "Toggle Font" button.The size of the combo box didn't change. Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java Changeset: 6c4b6780ab20 Author: rupashka Date: 2011-02-02 18:41 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6c4b6780ab20 6988176: There is focus painted inside the button. Reviewed-by: alexp ! src/share/classes/sun/swing/WindowsPlacesBar.java Changeset: 057e9b837105 Author: rupashka Date: 2011-02-03 16:30 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/057e9b837105 7013453: BufferStrategyPaintManager.dispose will cause IllegalMonitorStateException in event thread Reviewed-by: alexp ! src/share/classes/javax/swing/BufferStrategyPaintManager.java + test/javax/swing/RepaintManager/7013453/bug7013453.java Changeset: 0fae79ec7248 Author: naoto Date: 2011-02-03 09:59 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0fae79ec7248 7013282: No appropriate CCC request for listed JDK 7 changes in java.util.spi package (b121) Reviewed-by: peytoia ! src/share/classes/java/util/spi/LocaleNameProvider.java Changeset: c7e368a95c75 Author: alexp Date: 2011-02-07 21:15 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c7e368a95c75 7016942: Revert a refactoring in TooltipManager to allow reflection hack Reviewed-by: rupashka ! src/share/classes/javax/swing/ToolTipManager.java Changeset: 989f6d3eee0d Author: alexp Date: 2011-02-07 21:34 +0300 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/989f6d3eee0d 6979537: closed/javax/swing/JSplitPane/UnitTest/UnitTest.java fails Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java Changeset: 842a0f8c89ea Author: naoto Date: 2011-02-08 09:04 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/842a0f8c89ea 7015500: Locale.toLanguageTag() uses "und" as lang subtag for private use only Locale Reviewed-by: srl ! src/share/classes/java/util/Locale.java ! src/share/classes/sun/util/locale/LanguageTag.java ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: d002fe0c57c5 Author: lana Date: 2011-02-08 14:19 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d002fe0c57c5 Merge Changeset: dbfc1e419cb2 Author: darcy Date: 2011-01-24 20:04 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dbfc1e419cb2 7006578: Project Coin: Retrofit JDK libraries with @SafeVarargs Reviewed-by: mduigou, alexp ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/sun/swing/AccumulativeRunnable.java Changeset: ae38d1374e31 Author: mullan Date: 2011-01-24 14:56 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ae38d1374e31 5001004: Required Security Algorithms need to be defined Reviewed-by: wetmore ! src/share/classes/java/security/AlgorithmParameterGenerator.java ! src/share/classes/java/security/AlgorithmParameters.java ! src/share/classes/java/security/KeyFactory.java ! src/share/classes/java/security/KeyPairGenerator.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/MessageDigest.java ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/SecureRandom.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/Signature.java ! src/share/classes/java/security/cert/CertPath.java ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/CertStore.java ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/CertificateFactory.java ! src/share/classes/java/security/cert/CertificateFactorySpi.java ! src/share/classes/java/security/cert/package.html ! src/share/classes/java/security/package.html ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/ExemptionMechanism.java ! src/share/classes/javax/crypto/KeyAgreement.java ! src/share/classes/javax/crypto/KeyGenerator.java ! src/share/classes/javax/crypto/Mac.java ! src/share/classes/javax/crypto/SecretKeyFactory.java ! src/share/classes/javax/crypto/package.html ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/net/ssl/package.html ! src/share/classes/javax/security/auth/login/Configuration.java ! src/share/classes/javax/security/auth/login/package.html Changeset: b33e9b15835e Author: mullan Date: 2011-01-24 15:08 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b33e9b15835e Merge - make/common/internal/BinaryPlugs.gmk - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/classes/java/dyn/JavaMethodHandle.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java ! src/share/classes/java/security/Security.java ! src/share/classes/javax/net/ssl/SSLContext.java - src/share/classes/sun/java2d/pisces/LineSink.java - src/share/classes/sun/net/httpserver/SelectorCache.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java - test/sun/security/krb5/auto/basic.sh Changeset: 6ac9383640c6 Author: mullan Date: 2011-01-24 15:46 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6ac9383640c6 Merge Changeset: 6e7bed89ce84 Author: mullan Date: 2011-01-25 08:41 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6e7bed89ce84 Merge Changeset: bf1b937076db Author: alanb Date: 2011-01-26 18:01 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bf1b937076db 7012663: javadoc warning in javax.swing.JComponent and javax.swing.plaf.synth.SynthTextPaneUI Reviewed-by: alexp ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java Changeset: abab55565eda Author: darcy Date: 2011-01-26 12:32 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/abab55565eda 7013420: Project Coin: remove general expression support from try-with-resources statement Reviewed-by: alanb ! test/java/nio/channels/FileChannel/Truncate.java Changeset: 236e3f2d0a6b Author: alanb Date: 2011-01-28 09:28 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/236e3f2d0a6b 7006126: (fs) Updates to file system API (1/2011) Reviewed-by: chegar, sherman ! make/java/java/FILES_java.gmk ! make/java/nio/FILES_java.gmk ! make/mkdemo/Makefile ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/SerialCallbackContext.java - src/share/classes/java/io/TempFileHelper.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/SeekableByteChannel.java ! src/share/classes/java/nio/file/AccessMode.java + src/share/classes/java/nio/file/CopyMoveHelper.java ! src/share/classes/java/nio/file/CopyOption.java ! src/share/classes/java/nio/file/DirectoryStream.java - src/share/classes/java/nio/file/FileRef.java ! src/share/classes/java/nio/file/FileStore.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/FileSystems.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/FileVisitor.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/LinkOption.java ! src/share/classes/java/nio/file/LinkPermission.java ! src/share/classes/java/nio/file/OpenOption.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/PathMatcher.java ! src/share/classes/java/nio/file/Paths.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java + src/share/classes/java/nio/file/TempFileHelper.java ! src/share/classes/java/nio/file/WatchEvent.java ! src/share/classes/java/nio/file/WatchKey.java ! src/share/classes/java/nio/file/WatchService.java ! src/share/classes/java/nio/file/attribute/AclEntry.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java - src/share/classes/java/nio/file/attribute/Attributes.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java ! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java ! src/share/classes/java/nio/file/attribute/DosFileAttributes.java ! src/share/classes/java/nio/file/attribute/FileAttribute.java ! src/share/classes/java/nio/file/attribute/FileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileOwnerAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java ! src/share/classes/java/nio/file/attribute/FileTime.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributes.java ! src/share/classes/java/nio/file/attribute/PosixFilePermission.java ! src/share/classes/java/nio/file/attribute/PosixFilePermissions.java ! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java ! src/share/classes/java/nio/file/attribute/package-info.java ! src/share/classes/java/nio/file/package-info.java ! src/share/classes/java/nio/file/spi/FileSystemProvider.java ! src/share/classes/java/nio/file/spi/FileTypeDetector.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/sun/nio/fs/AbstractAclFileAttributeView.java ! src/share/classes/sun/nio/fs/AbstractBasicFileAttributeView.java + src/share/classes/sun/nio/fs/AbstractFileSystemProvider.java ! src/share/classes/sun/nio/fs/AbstractFileTypeDetector.java ! src/share/classes/sun/nio/fs/AbstractPath.java ! src/share/classes/sun/nio/fs/AbstractPoller.java ! src/share/classes/sun/nio/fs/AbstractUserDefinedFileAttributeView.java ! src/share/classes/sun/nio/fs/AbstractWatchKey.java ! src/share/classes/sun/nio/fs/AbstractWatchService.java ! src/share/classes/sun/nio/fs/DynamicFileAttributeView.java ! src/share/classes/sun/nio/fs/FileOwnerAttributeViewImpl.java ! src/share/classes/sun/nio/fs/PollingWatchService.java ! src/share/classes/sun/security/provider/SeedGenerator.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/sample/nio/file/AclEdit.java ! src/share/sample/nio/file/Chmod.java ! src/share/sample/nio/file/Copy.java ! src/share/sample/nio/file/DiskUsage.java ! src/share/sample/nio/file/FileType.java ! src/share/sample/nio/file/WatchDir.java ! src/share/sample/nio/file/Xdd.java ! src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxWatchService.java ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! src/solaris/classes/sun/nio/fs/UnixCopyFile.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java ! src/windows/classes/sun/nio/fs/RegistryFileTypeDetector.java ! src/windows/classes/sun/nio/fs/WindowsFileAttributeViews.java ! src/windows/classes/sun/nio/fs/WindowsFileCopy.java ! src/windows/classes/sun/nio/fs/WindowsFileStore.java ! src/windows/classes/sun/nio/fs/WindowsFileSystem.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! src/windows/classes/sun/nio/fs/WindowsPathParser.java ! src/windows/classes/sun/nio/fs/WindowsSecurityDescriptor.java ! src/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java ! src/windows/classes/sun/nio/fs/WindowsWatchService.java ! test/demo/zipfs/basic.sh ! test/java/io/File/IsHidden.java ! test/java/io/File/SetAccess.java ! test/java/io/File/SymLinks.java ! test/java/io/FileInputStream/LargeFileAvailable.java ! test/java/nio/channels/FileChannel/AtomicAppend.java ! test/java/nio/channels/FileChannel/Transfer.java ! test/java/nio/file/DirectoryStream/Basic.java ! test/java/nio/file/DirectoryStream/DriveLetter.java ! test/java/nio/file/DirectoryStream/SecureDS.java ! test/java/nio/file/FileStore/Basic.java + test/java/nio/file/Files/BytesAndLines.java + test/java/nio/file/Files/CheckPermissions.java - test/java/nio/file/Files/ContentType.java + test/java/nio/file/Files/CopyAndMove.java - test/java/nio/file/Files/CreateFileTree.java + test/java/nio/file/Files/DeleteOnClose.java + test/java/nio/file/Files/FileAttributes.java - test/java/nio/file/Files/ForceLoad.java + test/java/nio/file/Files/InterruptCopy.java + test/java/nio/file/Files/Links.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java ! test/java/nio/file/Files/Misc.java + test/java/nio/file/Files/PassThroughFileSystem.java - test/java/nio/file/Files/PrintFileTree.java + test/java/nio/file/Files/SBC.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java + test/java/nio/file/Files/TemporaryFiles.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java + test/java/nio/file/Files/delete_on_close.sh - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy + test/java/nio/file/Files/probeContentType/Basic.java + test/java/nio/file/Files/probeContentType/ForceLoad.java + test/java/nio/file/Files/probeContentType/META-INF/services/java.nio.file.spi.FileTypeDetector + test/java/nio/file/Files/probeContentType/SimpleFileTypeDetector.java + test/java/nio/file/Files/walkFileTree/CreateFileTree.java + test/java/nio/file/Files/walkFileTree/MaxDepth.java + test/java/nio/file/Files/walkFileTree/Nulls.java + test/java/nio/file/Files/walkFileTree/PrintFileTree.java + test/java/nio/file/Files/walkFileTree/SkipSiblings.java + test/java/nio/file/Files/walkFileTree/TerminateWalk.java + test/java/nio/file/Files/walkFileTree/WalkWithSecurity.java + test/java/nio/file/Files/walkFileTree/denyAll.policy + test/java/nio/file/Files/walkFileTree/grantAll.policy + test/java/nio/file/Files/walkFileTree/grantTopOnly.policy + test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java ! test/java/nio/file/Path/Misc.java - test/java/nio/file/Path/PassThroughFileSystem.java ! test/java/nio/file/Path/PathOps.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh ! test/java/nio/file/TestUtil.java ! test/java/nio/file/WatchService/Basic.java ! test/java/nio/file/WatchService/FileTreeModifier.java ! test/java/nio/file/WatchService/LotsOfEvents.java ! test/java/nio/file/WatchService/SensitivityModifier.java ! test/java/nio/file/attribute/AclFileAttributeView/Basic.java ! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java ! test/java/nio/file/attribute/DosFileAttributeView/Basic.java - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java ! test/java/nio/file/attribute/FileTime/Basic.java ! test/java/nio/file/attribute/PosixFileAttributeView/Basic.java ! test/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java ! test/java/nio/file/spi/SetDefaultProvider.java ! test/java/nio/file/spi/TestProvider.java Changeset: 60d347deb54d Author: alanb Date: 2011-01-28 09:31 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/60d347deb54d Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java ! test/demo/zipfs/basic.sh - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: dea360853f8b Author: alanb Date: 2011-01-28 13:26 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dea360853f8b 7015410: test/java/net/Socks/SocksProxyVersion.java needs to be updated due to 7013420 Reviewed-by: chegar ! test/java/net/Socks/SocksProxyVersion.java Changeset: d21a1ce074a7 Author: darcy Date: 2011-01-28 17:09 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d21a1ce074a7 7015156: Remove JSR 308 changes from core libraries Reviewed-by: mduigou ! src/share/classes/java/lang/SuppressWarnings.java ! src/share/classes/java/lang/annotation/ElementType.java Changeset: f110edeb4428 Author: darcy Date: 2011-02-01 00:29 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f110edeb4428 7015827: Fix HTML validation issues in java.math package Reviewed-by: mduigou ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/RoundingMode.java Changeset: d4bc38aa7594 Author: xuelei Date: 2011-02-01 04:45 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d4bc38aa7594 7011497: new CertPathValidatorException.BasicReason enum constant for constrained algorithm Summary: add new BasicReason and improve trust anchor searching method during cert path validation Reviewed-by: mullan ! src/share/classes/java/security/cert/CertPathValidatorException.java + src/share/classes/sun/security/provider/certpath/AdaptableX509CertSelector.java ! src/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/validator/SimpleValidator.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java Changeset: 21d7cd823247 Author: sundar Date: 2011-02-01 21:00 +0530 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/21d7cd823247 7015908: 3 javax.script tests fail with openjdk build Reviewed-by: alanb ! test/javax/script/CauseExceptionTest.java ! test/javax/script/StringWriterPrintTest.java ! test/javax/script/UnescapedBracketRegExTest.java Changeset: 312dc0abb960 Author: sherman Date: 2011-02-01 14:20 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/312dc0abb960 7015391: (zipfs) Update zip provider for 1/2011 changes 7014948: (zipfs) ZipFileSystem.newFileSystem(Path...) should not throw FileSystemAlreadyExistsException 7015139: (zipfs) ZipPath.delete() should throw DirectoryNotEmptyException when handling "real, non-empty" dir Summary: zip filesystem provider update Reviewed-by: alanb ! make/mkdemo/Makefile ! src/share/demo/nio/zipfs/Demo.java ! src/share/demo/nio/zipfs/README.txt ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributeView.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java - src/share/demo/zipfs ! test/demo/zipfs/Basic.java ! test/demo/zipfs/PathOps.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: 25462d7eee24 Author: briangoetz Date: 2011-02-02 13:13 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/25462d7eee24 7012540: java.util.Objects.nonNull() incorrectly named Reviewed-by: darcy, weijun ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/lang/StackTraceElement.java ! src/share/classes/java/nio/file/DirectoryIteratorException.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Objects.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! test/java/util/Objects/BasicObjectsTest.java Changeset: 3c86f24f7500 Author: chegar Date: 2011-02-03 10:10 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3c86f24f7500 7008595: Class loader leak caused by keepAliveTimer thread in KeepAliveCache Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/KeepAliveCache.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java Changeset: dff9b6d18628 Author: coffeys Date: 2011-02-03 11:28 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dff9b6d18628 7016897: Copyright header correction : test/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java Reviewed-by: vinnie ! test/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java Changeset: 0f5dc2fc81b1 Author: chegar Date: 2011-02-03 11:56 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0f5dc2fc81b1 6887710: Jar index should avoid putting META-INF in the INDEX.LIST Reviewed-by: michaelm ! src/share/classes/sun/misc/JarIndex.java + test/sun/misc/JarIndex/metaInfFilenames/Basic.java + test/sun/misc/JarIndex/metaInfFilenames/jarA/META-INF/services/my.happy.land + test/sun/misc/JarIndex/metaInfFilenames/jarA/a/A.java + test/sun/misc/JarIndex/metaInfFilenames/jarA/com/message/spi/MessageService.java + test/sun/misc/JarIndex/metaInfFilenames/jarB/META-INF/JAVA2.DS + test/sun/misc/JarIndex/metaInfFilenames/jarB/META-INF/services/no.name.service + test/sun/misc/JarIndex/metaInfFilenames/jarB/b/B.java + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/fonts.mf + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/fonts/Company-corporate.ttf + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/fonts/kidpr.ttf + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/services/com.message.spi.MessageService + test/sun/misc/JarIndex/metaInfFilenames/jarC/my/impl/StandardMessageService.java Changeset: 68e3eba12afe Author: michaelm Date: 2011-02-03 12:57 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/68e3eba12afe 6751021: TEST_BUG: race condition in the test java/lang/Runtime/exec/Duped.java Reviewed-by: alanb ! test/java/lang/Runtime/exec/Duped.java Changeset: e2a182adb30f Author: alanb Date: 2011-02-03 13:37 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e2a182adb30f 7014794: (file) lookupPrincipalByGroupName fails to find large NIS groups Reviewed-by: chegar ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c Changeset: 515512634eb4 Author: vinnie Date: 2011-02-03 19:09 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/515512634eb4 6997561: A request for better error handling in JNDI Reviewed-by: robm ! src/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java + test/com/sun/jndi/ldap/LdapName/EmptyNameSearch.java Changeset: 035ecca4379c Author: sherman Date: 2011-02-03 13:49 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/035ecca4379c 7014645: Support perl style Unicode hex notation \x{...} Summary: Added the construct \x{...} for Unicode hex notation support Reviewed-by: alanb, okutsu ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: 3c1eca364cc7 Author: ksrini Date: 2011-02-03 15:41 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3c1eca364cc7 6968053: (launcher) hide exceptions under certain launcher failures Reviewed-by: mchung ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/misc/VM.java ! test/tools/launcher/Arrrghs.java Changeset: 1b5c838b8db8 Author: vinnie Date: 2011-02-04 00:33 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1b5c838b8db8 6989705: ECC security code native code compiler warnings Reviewed-by: alanb, ohair ! src/share/native/sun/security/ec/ECC_JNI.cpp ! src/share/native/sun/security/ec/impl/ec.c ! src/share/native/sun/security/ec/impl/ec.h ! src/share/native/sun/security/ec/impl/ec2.h ! src/share/native/sun/security/ec/impl/ec2_163.c ! src/share/native/sun/security/ec/impl/ec2_193.c ! src/share/native/sun/security/ec/impl/ec2_233.c ! src/share/native/sun/security/ec/impl/ec2_aff.c ! src/share/native/sun/security/ec/impl/ec2_mont.c ! src/share/native/sun/security/ec/impl/ec_naf.c ! src/share/native/sun/security/ec/impl/ecc_impl.h ! src/share/native/sun/security/ec/impl/ecdecode.c ! src/share/native/sun/security/ec/impl/ecl-curve.h ! src/share/native/sun/security/ec/impl/ecl-exp.h ! src/share/native/sun/security/ec/impl/ecl-priv.h ! src/share/native/sun/security/ec/impl/ecl.c ! src/share/native/sun/security/ec/impl/ecl.h ! src/share/native/sun/security/ec/impl/ecl_curve.c ! src/share/native/sun/security/ec/impl/ecl_gf.c ! src/share/native/sun/security/ec/impl/ecl_mult.c ! src/share/native/sun/security/ec/impl/ecp.h ! src/share/native/sun/security/ec/impl/ecp_192.c ! src/share/native/sun/security/ec/impl/ecp_224.c ! src/share/native/sun/security/ec/impl/ecp_256.c ! src/share/native/sun/security/ec/impl/ecp_384.c ! src/share/native/sun/security/ec/impl/ecp_521.c ! src/share/native/sun/security/ec/impl/ecp_aff.c ! src/share/native/sun/security/ec/impl/ecp_jac.c ! src/share/native/sun/security/ec/impl/ecp_jm.c ! src/share/native/sun/security/ec/impl/ecp_mont.c ! src/share/native/sun/security/ec/impl/logtab.h ! src/share/native/sun/security/ec/impl/mp_gf2m-priv.h ! src/share/native/sun/security/ec/impl/mp_gf2m.c ! src/share/native/sun/security/ec/impl/mp_gf2m.h ! src/share/native/sun/security/ec/impl/mpi-config.h ! src/share/native/sun/security/ec/impl/mpi-priv.h ! src/share/native/sun/security/ec/impl/mpi.c ! src/share/native/sun/security/ec/impl/mpi.h ! src/share/native/sun/security/ec/impl/mplogic.c ! src/share/native/sun/security/ec/impl/mplogic.h ! src/share/native/sun/security/ec/impl/mpmontg.c ! src/share/native/sun/security/ec/impl/mpprime.h ! src/share/native/sun/security/ec/impl/oid.c ! src/share/native/sun/security/ec/impl/secitem.c ! src/share/native/sun/security/ec/impl/secoidt.h Changeset: fed61c2f4d14 Author: vinnie Date: 2011-02-04 00:33 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fed61c2f4d14 Merge Changeset: 78fe1b7a9a1a Author: vinnie Date: 2011-02-04 09:52 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/78fe1b7a9a1a 7017176: Several JNDI tests are mssing GPL header Reviewed-by: alanb ! test/com/sun/jndi/ldap/LdapName/Case.java ! test/com/sun/jndi/ldap/LdapName/EmptyNameSearch.java ! test/com/sun/jndi/ldap/LdapName/UnescapeTest.java ! test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 9599534b1727 Author: lancea Date: 2011-02-04 09:07 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9599534b1727 7014095: Broken link in java.sql package specification Reviewed-by: alanb ! src/share/classes/java/sql/package.html Changeset: c5f953e920c6 Author: mduigou Date: 2011-02-04 12:54 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c5f953e920c6 7015783: Update JDK Netbeans projects to -source 1.7 Reviewed-by: darcy ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent Changeset: b8662dac7c91 Author: sherman Date: 2011-02-04 13:17 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b8662dac7c91 7005986: (zipfs) ZipPath.startsWith() fails because of the implementation of getName(index) Summary: Updated starsWith/endsWith to be consistent with default file system Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java ! test/demo/zipfs/PathOps.java ! test/demo/zipfs/basic.sh Changeset: a775b8d3fed0 Author: lana Date: 2011-02-04 17:29 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a775b8d3fed0 Merge - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties Changeset: b0bd638036bd Author: vinnie Date: 2011-02-07 09:11 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b0bd638036bd 7017486: Need synchronized access when flushing the LDAP request queue Reviewed-by: alanb ! src/share/classes/com/sun/jndi/ldap/Connection.java Changeset: f34dcfeecc8d Author: alanb Date: 2011-02-07 13:53 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f34dcfeecc8d 7012823: TEST_BUG: java/nio/MappedByteBuffer tests leave file mappingsthat prevent clean-up (win) Reviewed-by: forax ! test/java/nio/MappedByteBuffer/Force.java ! test/java/nio/MappedByteBuffer/ZeroMap.java Changeset: 32f1c5f67aae Author: alanb Date: 2011-02-07 13:55 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/32f1c5f67aae 7003155: (fs) Paths.get() does not handle escaped octets correctly Reviewed-by: sherman ! src/solaris/classes/sun/nio/fs/UnixUriUtils.java ! test/java/nio/file/Path/UriImportExport.java Changeset: 94bcd9aa2119 Author: chegar Date: 2011-02-07 14:08 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/94bcd9aa2119 7016898: PlainSocketImpl.fd is null on Windows Reviewed-by: alanb ! src/windows/classes/java/net/PlainSocketImpl.java Changeset: f9f321a7502c Author: alanb Date: 2011-02-07 18:01 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f9f321a7502c 7017454: Residual warnings in sun/nio/** and java/io native code (win64) Reviewed-by: chegar ! src/share/native/java/io/io_util.c ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/canonicalize_md.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/sun/nio/ch/Iocp.c ! src/windows/native/sun/nio/fs/RegistryFileTypeDetector.c ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c Changeset: 08e1914d5852 Author: alanb Date: 2011-02-07 18:02 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/08e1914d5852 Merge Changeset: 947ce00ed7a2 Author: alanb Date: 2011-02-08 15:50 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/947ce00ed7a2 7013585: Dual-pivot quicksort improvements for highly structured (nearly sorted) and data with small periods Reviewed-by: mduigou, alanb Contributed-by: vladimir.yaroslavskiy at oracle.com ! src/share/classes/java/util/DualPivotQuicksort.java ! test/java/util/Arrays/Sorting.java Changeset: 82c8c54ac1d5 Author: alanb Date: 2011-02-08 19:31 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/82c8c54ac1d5 4421494: infinite loop while parsing double literal Reviewed-by: darcy, alanb Contributed-by: dmitry.nadezhin at oracle.com ! src/share/classes/sun/misc/FloatingDecimal.java ! test/java/lang/Double/ParseDouble.java Changeset: 6661a1dfa369 Author: sherman Date: 2011-02-08 13:30 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6661a1dfa369 7017840: (zipfs) test/demo/zipfs/basic.sh needs to be updated due to 7013420 Summary: updated try-with-resourcse usage in test/demo code Reviewed-by: alanb ! src/share/demo/nio/zipfs/Demo.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: 1899523d8f24 Author: lana Date: 2011-02-08 14:25 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1899523d8f24 Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: cd9a302f2806 Author: chegar Date: 2011-02-09 09:53 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cd9a302f2806 7013961: Threads attached via JNI attach prevent daemon ThreadGroups from being destroyed Reviewed-by: dholmes ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java Changeset: 6a274c4d3e00 Author: alanb Date: 2011-02-09 15:59 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6a274c4d3e00 7018258: Dual-pivot updates in 7013585 can fail with ArrayIndexOutOfBoundsException Reviewed-by: alanb Contributed-by: vladimir.yaroslavskiy at oracle.com ! src/share/classes/java/util/DualPivotQuicksort.java ! test/java/util/Arrays/Sorting.java Changeset: 37563c09305d Author: alanb Date: 2011-02-09 16:30 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/37563c09305d Merge Changeset: a8fcaf5097ec Author: lana Date: 2011-02-09 10:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a8fcaf5097ec Merge Changeset: 9d141e45ee4b Author: lana Date: 2011-02-14 16:30 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9d141e45ee4b Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: e4802c87e5c7 Author: herrick Date: 2011-02-09 09:19 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e4802c87e5c7 7016724: Remove sun.jkernel.* classes in JDK 7 Summary: Remove sun.jkernel.* classes in JDK 7 Reviewed-by: ohair, alanb, mchung ! make/modules/modules.config ! make/sun/Makefile - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/util/zip/ZipEntry.java - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java ! src/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java ! src/share/classes/sun/misc/BootClassLoaderHook.java ! src/share/classes/sun/tools/attach/HotSpotAttachProvider.java ! src/windows/bin/java_md.c - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc Changeset: dc909d130397 Author: herrick Date: 2011-02-09 09:32 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/dc909d130397 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 4f84cda2a7d5 Author: igor Date: 2011-02-09 21:20 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4f84cda2a7d5 Merge - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc Changeset: 802c085308bf Author: igor Date: 2011-02-15 19:16 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/802c085308bf Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: 7bb09178ffc7 Author: ohair Date: 2011-02-10 20:45 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7bb09178ffc7 7012644: Regression: jdk/make/common/shared/Defs-windows.gmk has problems on cygwin 7018835: Debug build issues in jdk makefiles Reviewed-by: ksrini ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Platform.gmk Changeset: 9478964f9425 Author: ohair Date: 2011-02-10 20:51 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9478964f9425 Merge Changeset: 71b52ce5f389 Author: mfang Date: 2011-02-10 20:52 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/71b52ce5f389 7017734: jdk7 message drop 1 translation integration Reviewed-by: ogino, yhuang ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ja.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ko.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_CN.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_es.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_it.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ja.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ko.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_sv.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_es.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_fr.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ja.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_sv.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_es.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_fr.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_it.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_sv.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_de.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_es.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_it.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_de.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_es.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_it.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties ! src/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties ! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_es.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_fr.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_it.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ja.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ko.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_sv.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_TW.java ! src/share/classes/sun/awt/resources/awt_de.properties ! src/share/classes/sun/awt/resources/awt_es.properties ! src/share/classes/sun/awt/resources/awt_fr.properties ! src/share/classes/sun/awt/resources/awt_it.properties ! src/share/classes/sun/awt/resources/awt_ja.properties ! src/share/classes/sun/awt/resources/awt_ko.properties ! src/share/classes/sun/awt/resources/awt_pt_BR.properties ! src/share/classes/sun/awt/resources/awt_sv.properties ! src/share/classes/sun/awt/resources/awt_zh_CN.properties ! src/share/classes/sun/awt/resources/awt_zh_TW.properties ! src/share/classes/sun/management/resources/agent_de.properties ! src/share/classes/sun/management/resources/agent_es.properties ! src/share/classes/sun/management/resources/agent_fr.properties ! src/share/classes/sun/management/resources/agent_it.properties ! src/share/classes/sun/management/resources/agent_ja.properties ! src/share/classes/sun/management/resources/agent_ko.properties ! src/share/classes/sun/management/resources/agent_pt_BR.properties ! src/share/classes/sun/management/resources/agent_sv.properties ! src/share/classes/sun/management/resources/agent_zh_CN.properties ! src/share/classes/sun/management/resources/agent_zh_TW.properties ! src/share/classes/sun/misc/resources/Messages_de.java ! src/share/classes/sun/misc/resources/Messages_es.java ! src/share/classes/sun/misc/resources/Messages_fr.java ! src/share/classes/sun/misc/resources/Messages_it.java ! src/share/classes/sun/misc/resources/Messages_ja.java ! src/share/classes/sun/misc/resources/Messages_ko.java ! src/share/classes/sun/misc/resources/Messages_pt_BR.java ! src/share/classes/sun/misc/resources/Messages_sv.java ! src/share/classes/sun/misc/resources/Messages_zh_CN.java ! src/share/classes/sun/misc/resources/Messages_zh_TW.java ! src/share/classes/sun/print/resources/serviceui_de.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_ja.properties ! src/share/classes/sun/print/resources/serviceui_ko.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/print/resources/serviceui_zh_CN.properties ! src/share/classes/sun/print/resources/serviceui_zh_TW.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_es.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_fr.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_it.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ja.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ko.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_sv.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_CN.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_TW.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_ja.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_de.properties ! src/share/classes/sun/rmi/server/resources/rmid_es.properties ! src/share/classes/sun/rmi/server/resources/rmid_fr.properties ! src/share/classes/sun/rmi/server/resources/rmid_it.properties ! src/share/classes/sun/rmi/server/resources/rmid_ja.properties ! src/share/classes/sun/rmi/server/resources/rmid_ko.properties ! src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties ! src/share/classes/sun/rmi/server/resources/rmid_sv.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_TW.properties ! src/share/classes/sun/security/tools/JarSignerResources_ja.java ! src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_de.java ! src/share/classes/sun/security/util/AuthResources_es.java ! src/share/classes/sun/security/util/AuthResources_fr.java ! src/share/classes/sun/security/util/AuthResources_it.java ! src/share/classes/sun/security/util/AuthResources_ja.java ! src/share/classes/sun/security/util/AuthResources_ko.java ! src/share/classes/sun/security/util/AuthResources_pt_BR.java ! src/share/classes/sun/security/util/AuthResources_sv.java ! src/share/classes/sun/security/util/AuthResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_zh_TW.java ! src/share/classes/sun/security/util/Resources_de.java ! src/share/classes/sun/security/util/Resources_es.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java ! src/share/classes/sun/security/util/Resources_ja.java ! src/share/classes/sun/security/util/Resources_ko.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/security/util/Resources_sv.java ! src/share/classes/sun/security/util/Resources_zh_CN.java ! src/share/classes/sun/security/util/Resources_zh_TW.java ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/share/classes/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_ja.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_zh_CN.java ! src/share/classes/sun/tools/serialver/serialver_ja.properties ! src/share/classes/sun/tools/serialver/serialver_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_de.properties ! src/share/classes/sun/util/logging/resources/logging_es.properties ! src/share/classes/sun/util/logging/resources/logging_fr.properties ! src/share/classes/sun/util/logging/resources/logging_it.properties ! src/share/classes/sun/util/logging/resources/logging_ja.properties ! src/share/classes/sun/util/logging/resources/logging_ko.properties ! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties ! src/share/classes/sun/util/logging/resources/logging_sv.properties ! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties ! src/share/demo/jfc/CodePointIM/resources/codepoint_ja.properties ! src/share/demo/jfc/CodePointIM/resources/codepoint_zh_CN.properties ! src/share/demo/jfc/Font2DTest/resources/TextResources_ja.properties ! src/share/demo/jfc/Font2DTest/resources/TextResources_zh_CN.properties ! src/share/demo/jfc/Notepad/resources/Notepad_ja.properties ! src/share/demo/jfc/Notepad/resources/Notepad_zh_CN.properties ! src/windows/classes/sun/awt/windows/awtLocalization_es.properties ! src/windows/classes/sun/awt/windows/awtLocalization_ja.properties ! src/windows/classes/sun/awt/windows/awtLocalization_ko.properties ! src/windows/classes/sun/awt/windows/awtLocalization_pt_BR.properties ! src/windows/classes/sun/awt/windows/awtLocalization_zh_CN.properties ! src/windows/classes/sun/awt/windows/awtLocalization_zh_TW.properties ! src/windows/native/sun/jkernel/kernel_de.rc ! src/windows/native/sun/jkernel/kernel_es.rc ! src/windows/native/sun/jkernel/kernel_fr.rc ! src/windows/native/sun/jkernel/kernel_it.rc ! src/windows/native/sun/jkernel/kernel_ja.rc ! src/windows/native/sun/jkernel/kernel_ko.rc ! src/windows/native/sun/jkernel/kernel_pt_BR.rc ! src/windows/native/sun/jkernel/kernel_sv.rc ! src/windows/native/sun/jkernel/kernel_zh.rc ! src/windows/native/sun/jkernel/kernel_zh_TW.rc Changeset: 8b6d1d96ef3d Author: mfang Date: 2011-02-11 22:57 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8b6d1d96ef3d Merge Changeset: 0eacbbc8e1fb Author: mfang Date: 2011-02-11 23:46 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0eacbbc8e1fb Merge Changeset: 780e53ad2896 Author: mfang Date: 2011-02-14 13:01 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/780e53ad2896 Merge Changeset: 5fab973e5a47 Author: ohair Date: 2011-02-15 12:34 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5fab973e5a47 Merge Changeset: bdc069d3f910 Author: ohair Date: 2011-02-15 20:18 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bdc069d3f910 Merge Changeset: 89055b6d9ae0 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/89055b6d9ae0 Added tag jdk7-b130 for changeset bdc069d3f910 ! .hgtags Changeset: 0355c60c2da4 Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0355c60c2da4 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 9b2631288894 Author: ohair Date: 2011-02-16 14:33 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9b2631288894 7010594: Add /SAFESEH to links on windows to verify safe exceptions Reviewed-by: alanb ! make/common/Defs-windows.gmk ! make/common/shared/Defs-windows.gmk Changeset: 5e09deee1967 Author: andrew Date: 2011-02-23 17:10 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5e09deee1967 7021314: Build should not install javaws man page Summary: Only install javaws.1 when not building OpenJDK Reviewed-by: alanb, ohair ! make/common/Release.gmk Changeset: 8ac52c85f9e9 Author: cl Date: 2011-02-23 15:49 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8ac52c85f9e9 Merge Changeset: 11c9a066a5a4 Author: cl Date: 2011-02-24 15:16 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/11c9a066a5a4 Added tag jdk7-b131 for changeset 8ac52c85f9e9 ! .hgtags Changeset: 6b160a0efd3b Author: mcimadamore Date: 2011-03-01 16:36 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6b160a0efd3b merge with jdk7-b131 - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile ! src/share/bin/java.c - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/share/demo/zipfs - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java - test/sun/security/krb5/auto/basic.sh From benjamin.john.evans at gmail.com Wed Mar 2 09:09:58 2011 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Wed, 2 Mar 2011 17:09:58 +0000 Subject: The lambda conversion and a lambda body that doesn't complete. In-Reply-To: References: Message-ID: OK, I'll bite. What's the interest in this use case? As I read it, you're saying that if the compiler can provably guarantee that a lambda cannot return normally, then the compiler should ignore the return type when SAM-converting. Is that the property we're after? What's the use case for this feature? How often are we actually going to write code inside a lambda which the compiler can guarantee will not return normally? Should we even be encouraging people to write code like that? Glaringly obvious use cases and other smackdown in 3-2-1.... :) Ben On Tue, Mar 1, 2011 at 5:35 PM, Neal Gafter wrote: > Dear Lambdans- > > Given > > *interface F { > int invoke(); > }* > > I would like to be able to write > > *F x = #{ throw new Exception(); }; > * > > (Modulo syntax - whatever the current syntax is) > > But according to the current draft specification that's not allowed (the > lambda as written can only be converted to a SAM with a void return type). > > I think that whether or not the lambda's body can complete normally should > be taken into account in the lambda conversion to make this legal. As a > point of information, the behavior I prefer is the behavior of Scala, BGGA, > and C# (among others). This is also consistent with the way method > implementations work: > > *int f() { throw new Exception(); }* > > In the unfortunate case that you need use cases for this, draft > specification language, or suggestions for a straightforward > implementation, > I can provide those. > > Cheers, > Neal > > From david.moss at ubs.com Wed Mar 2 09:21:59 2011 From: david.moss at ubs.com (david.moss at ubs.com) Date: Wed, 2 Mar 2011 18:21:59 +0100 Subject: The lambda conversion and a lambda body that doesn't complete. In-Reply-To: References: Message-ID: <9FF0EECF0E58D849A9D537E324DDDC0D07FF3FBA@NZURC102PEX1.ubsw.net> Well, At the very least it should be allowed because the following already is: interface I { int method(); } class C implements I { @Override public int method() { throw new RuntimeException("whatever"); } } Kind Regards, David. -----Original Message----- From: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Ben Evans Sent: 02 March 2011 18:10 To: Neal Gafter; lambda-dev Subject: Re: The lambda conversion and a lambda body that doesn't complete. OK, I'll bite. What's the interest in this use case? As I read it, you're saying that if the compiler can provably guarantee that a lambda cannot return normally, then the compiler should ignore the return type when SAM-converting. Is that the property we're after? What's the use case for this feature? How often are we actually going to write code inside a lambda which the compiler can guarantee will not return normally? Should we even be encouraging people to write code like that? Glaringly obvious use cases and other smackdown in 3-2-1.... :) Ben On Tue, Mar 1, 2011 at 5:35 PM, Neal Gafter wrote: > Dear Lambdans- > > Given > > *interface F { > int invoke(); > }* > > I would like to be able to write > > *F x = #{ throw new Exception(); }; > * > > (Modulo syntax - whatever the current syntax is) > > But according to the current draft specification that's not allowed > (the lambda as written can only be converted to a SAM with a void return type). > > I think that whether or not the lambda's body can complete normally > should be taken into account in the lambda conversion to make this > legal. As a point of information, the behavior I prefer is the > behavior of Scala, BGGA, and C# (among others). This is also > consistent with the way method implementations work: > > *int f() { throw new Exception(); }* > > In the unfortunate case that you need use cases for this, draft > specification language, or suggestions for a straightforward > implementation, I can provide those. > > Cheers, > Neal > > Based on the present E-Mail exchange, and/or on the agreement reached with you, respectively, UBS is entitled to contact you via insecure E-Mail: (a) E-Mails contain substantial risks such as lack of confidentiality, manipulation of content and sender, misdirection, viruses etc. UBS does not accept any liability for damages arising from use of E-mail. Accordingly, UBS recommends to abstain from sending any sensitive information via E-Mail, from forwarding the text received when submitting reply E-Mails and recommends to manually capture the E-Mail address in every instance. If you should wish to verify the content of this message, please request a hard-copy version. (b) In principle, UBS does not accept any (purchase) orders, cancellation of orders or authorizations etc. via E-mail. If UBS receives such E-Mails, UBS is not obliged to expressly decline them. If you have received this E-Mail by mistake or do not wish to be contacted by E-Mail in the future, you are kindly asked to inform UBS accordingly. Any E-Mail received by mistake (including all its annexes) needs to be destroyed and the content may not be forwarded nor disclosed to any further persons. c) This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. UBS reserves the right to retain all messages. Messages are protected and accessed only in legally justified cases. From forax at univ-mlv.fr Wed Mar 2 09:31:09 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 02 Mar 2011 18:31:09 +0100 Subject: The lambda conversion and a lambda body that doesn't complete. In-Reply-To: <9FF0EECF0E58D849A9D537E324DDDC0D07FF3FBA@NZURC102PEX1.ubsw.net> References: <9FF0EECF0E58D849A9D537E324DDDC0D07FF3FBA@NZURC102PEX1.ubsw.net> Message-ID: <4D6E7EDD.1000301@univ-mlv.fr> On 03/02/2011 06:21 PM, david.moss at ubs.com wrote: > Well, > > At the very least it should be allowed because the following already is: > > interface I { int method(); } > > class C implements I { > @Override > public int method() { > throw new RuntimeException("whatever"); > } > } > > > Kind Regards, > > David. This is not an argument. interface I { void m(T t); } ... I i = new I() { void m(T t) { ... } }; // ok I i = { T t -> ... }; // not ok I like to see lambdas as a more lightweight than inner classes. R?mi From forax at univ-mlv.fr Wed Mar 2 09:37:27 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 02 Mar 2011 18:37:27 +0100 Subject: The lambda conversion and a lambda body that doesn't complete. In-Reply-To: References: Message-ID: <4D6E8057.7000801@univ-mlv.fr> On 03/02/2011 06:09 PM, Ben Evans wrote: > OK, I'll bite. Fight ! fight ! > What's the interest in this use case? > > As I read it, you're saying that if the compiler can provably guarantee that > a lambda cannot return normally, then the compiler should ignore the return > type when SAM-converting. Is that the property we're after? Yes. The compiler should have internally a type corresponding to will never return. But this type doesn't have to have a surface syntax. > What's the use case for this feature? How often are we actually going to > write code inside a lambda which the compiler can guarantee will not return > normally? Should we even be encouraging people to write code like that? Use case: Error handlers like the ones used when doing charset conversions. Anyway we need that for completeness. > Glaringly obvious use cases and other smackdown in 3-2-1.... :) > > Ben R?mi From bobfoster at gmail.com Wed Mar 2 14:33:04 2011 From: bobfoster at gmail.com (Bob Foster) Date: Wed, 2 Mar 2011 14:33:04 -0800 Subject: lambda-dev Digest, Vol 16, Issue 6 In-Reply-To: References: Message-ID: Ben Evans wrote: > What's the use case for this feature? ... > Glaringly obvious use cases and other smackdown in 3-2-1.... :) java.lang.UnsupportedOperationException Bob From neal at gafter.com Fri Mar 4 11:16:09 2011 From: neal at gafter.com (Neal Gafter) Date: Fri, 4 Mar 2011 11:16:09 -0800 Subject: Inferring lambda parameter types in an argument position Message-ID: Dear Lambda- I'd like the lambda conversion to infer lambda parameter types even when the lambda appears in an argument position and the underlying method is overloaded. For example, given *interface Mapping { Out map(In in); } interface IndexedMapping { Out map(In in, int index); } interface Predicate { bool isSatisfied(E e); } interface MyList { MyList map(Mapping f) ...; MyList map(IndexedMapping f) ...; MyList filter(Predicate p) ... } * I would like to be able to write my lambdas with parameter types elided: * * *MyList list = ...;* *MyList newList = list .map( #{ x -> new Y(x) } ) .filter( #{ y -> y.IsFunny() } );* This is all modulo syntax. I'd prefer the syntax *MyList newList = list .map( x -> new Y(x) ) .filter( y -> y.IsFunny() ); * but that is a discussion for another day (just let us know which day). Cheers, Neal From forax at univ-mlv.fr Fri Mar 4 11:28:11 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 04 Mar 2011 20:28:11 +0100 Subject: Inferring lambda parameter types in an argument position In-Reply-To: References: Message-ID: <4D713D4B.50600@univ-mlv.fr> On 03/04/2011 08:16 PM, Neal Gafter wrote: > Dear Lambda- > > I'd like the lambda conversion to infer lambda parameter types even when the > lambda appears in an argument position and the underlying method is > overloaded. You're not the only one :) It's on the ToDo list but we haven't discuss yet about that. R?mi > For example, given > > *interface Mapping > { > Out map(In in); > } > interface IndexedMapping > { > Out map(In in, int index); > } > interface Predicate > { > bool isSatisfied(E e); > } > interface MyList { > MyList map(Mapping f) ...; > MyList map(IndexedMapping f) ...; > MyList filter(Predicate p) ... > } > * > > I would like to be able to write my lambdas with parameter types elided: > * > * > *MyList list = ...;* > *MyList newList = list > .map( #{ x -> new Y(x) } ) > .filter( #{ y -> y.IsFunny() } );* > > This is all modulo syntax. I'd prefer the syntax > > *MyList newList = list > .map( x -> new Y(x) ) > .filter( y -> y.IsFunny() ); > * > > but that is a discussion for another day (just let us know which day). > > Cheers, > Neal > From maurizio.cimadamore at oracle.com Fri Mar 4 12:11:36 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 04 Mar 2011 20:11:36 +0000 Subject: Inferring lambda parameter types in an argument position In-Reply-To: References: Message-ID: <4D714778.5010602@oracle.com> Hi Neal, I think we are on the same page here. The current compiler works *almost* fine - only problem is inference in chained calls (i.e. chained call to 'filter' in your example) - but we are working on it. Maurizio On 04/03/11 19:16, Neal Gafter wrote: > interface Mapping > { > Out map(In in); > } > interface IndexedMapping > { > Out map(In in, int index); > } > interface Predicate > { > bool isSatisfied(E e); > } > interface MyList { > MyList map(Mapping f) ...; > MyList map(IndexedMapping f) ...; > MyList filter(Predicate p) ... > } > * > > I would like to be able to write my lambdas with parameter types elided: > * > * > *MyList list = ...;* > *MyList newList = list > .map( #{ x -> new Y(x) } ) > .filter( #{ y -> y.IsFunny() } );* > > This is all modulo syntax. I'd prefer the syntax > > *MyList newList = list > .map( x -> new Y(x) ) > .filter( y -> y.IsFunny() ); > * From neal at gafter.com Fri Mar 4 14:18:25 2011 From: neal at gafter.com (Neal Gafter) Date: Fri, 4 Mar 2011 14:18:25 -0800 Subject: Inferring lambda parameter types in an argument position In-Reply-To: <4D714778.5010602@oracle.com> References: <4D714778.5010602@oracle.com> Message-ID: Maurizio- That's great! However, I should say I'm more concerned about the specification than about the current prototype, because 1. The prototype will change, but what we finally get is what we have to live with; 2. The implementation needs to agree with the specification, not merely appear to "do the right thing"; and 3. Getting the specification right is much harder, as the spec has to give some reasonable result in *all* cases, not just the ones that were encountered while developing the prototype. Also, there are interesting cases around nested lambdas with overload resolution that the spec should be capable of handling: *a.F( x -> x.G( y -> H(x, y) ) )* That said, I certainly agree that the prototyping effort is helping to figure out what to specify. Cheers, Neal On Fri, Mar 4, 2011 at 12:11 PM, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi Neal, > I think we are on the same page here. The current compiler works *almost* > fine - only problem is inference in chained calls (i.e. chained call to > 'filter' in your example) - but we are working on it. > > Maurizio > > > On 04/03/11 19:16, Neal Gafter wrote: > >> interface Mapping >> { >> Out map(In in); >> } >> interface IndexedMapping >> { >> Out map(In in, int index); >> } >> interface Predicate >> { >> bool isSatisfied(E e); >> } >> interface MyList { >> MyList map(Mapping f) ...; >> MyList map(IndexedMapping f) ...; >> MyList filter(Predicate p) ... >> } >> * >> >> I would like to be able to write my lambdas with parameter types elided: >> * >> * >> *MyList list = ...;* >> *MyList newList = list >> .map( #{ x -> new Y(x) } ) >> .filter( #{ y -> y.IsFunny() } );* >> >> This is all modulo syntax. I'd prefer the syntax >> >> *MyList newList = list >> .map( x -> new Y(x) ) >> .filter( y -> y.IsFunny() ); >> * >> > > From howard.lovatt at gmail.com Fri Mar 4 15:37:38 2011 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Sat, 5 Mar 2011 10:37:38 +1100 Subject: Compilation problem Message-ID: Hi, I am compiling the latest version of the SDK from the Mercurial repository and I get the following errors: build-bootstrap-javac: [javac] Compiling 29 source files to /Users/lov080/Downloads/MLVM/JDK7/langtools/build/bootstrap/classes [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:326: cannot find symbol [javac] if (!Files.exists(path)) [javac] ^ [javac] symbol: method exists(Path) [javac] location: class Files [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:341: cannot find symbol [javac] if (!Files.exists(packageDir)) [javac] ^ [javac] symbol: method exists(Path) [javac] location: class Files [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:376: cannot find symbol [javac] Path name = dir.getFileName(); [javac] ^ [javac] symbol: method getFileName() [javac] location: class Path [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:385: cannot find symbol [javac] if (attrs.isRegularFile() && kinds.contains(getKind(file.getFileName().toString()))) { [javac] ^ [javac] symbol: method getFileName() [javac] location: class Path [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:431: cannot find symbol [javac] if (Files.exists(f)) [javac] ^ [javac] symbol: method exists(Path) [javac] location: class Files [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:437: cannot find symbol [javac] if (Files.exists(file)) [javac] ^ [javac] symbol: method exists(Path) [javac] location: class Files [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:504: no suitable method found for newFileSystem(Path,) [javac] fs = FileSystems.newFileSystem(p, null); [javac] ^ [javac] method FileSystems.newFileSystem(FileRef,Map,ClassLoader) is not applicable [javac] (actual and formal argument lists differ in length) [javac] method FileSystems.newFileSystem(URI,Map,ClassLoader) is not applicable [javac] (actual and formal argument lists differ in length) [javac] method FileSystems.newFileSystem(URI,Map) is not applicable [javac] (actual argument Path cannot be converted to URI by method invocation conversion) [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:530: cannot find symbol [javac] BasicFileAttributes attrs = Files.readAttributes(path, BasicFileAttributes.class); [javac] ^ [javac] symbol: method readAttributes(Path,Class) [javac] location: class Files [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:155: cannot find symbol [javac] return BaseFileManager.getKind(path.getFileName().toString()); [javac] ^ [javac] symbol: method getFileName() [javac] location: class Path [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:166: cannot find symbol [javac] String pn = path.getFileName().toString(); [javac] ^ [javac] symbol: method getFileName() [javac] location: class Path [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:173: cannot find symbol [javac] return path.toRealPath(false).getFileName().toString().equals(sn); [javac] ^ [javac] symbol: method getFileName() [javac] location: class Path [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:202: cannot find symbol [javac] return Files.newInputStream(path); [javac] ^ [javac] symbol: method newInputStream(Path) [javac] location: class Files [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:208: cannot find symbol [javac] return Files.newOutputStream(path); [javac] ^ [javac] symbol: method newOutputStream(Path) [javac] location: class Files [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:244: cannot find symbol [javac] return new OutputStreamWriter(Files.newOutputStream(path), fileManager.getEncodingName()); [javac] ^ [javac] symbol: method newOutputStream(Path) [javac] location: class Files [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:250: cannot find symbol [javac] return Files.getLastModifiedTime(path).toMillis(); [javac] ^ [javac] symbol: method getLastModifiedTime(Path) [javac] location: class Files [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:259: cannot find symbol [javac] Files.delete(path); [javac] ^ [javac] symbol: method delete(Path) [javac] location: class Files [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:268: cannot find symbol [javac] return Files.isSameFile(path, other.path); [javac] ^ [javac] symbol: method isSameFile(Path,Path) [javac] location: class Files [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:297: cannot find symbol [javac] return Files.size(path); [javac] ^ [javac] symbol: method size(Path) [javac] location: class Files [javac] 18 errors BUILD FAILED /Users/lov080/Downloads/MLVM/JDK7/langtools/make/build.xml:452: The following error occurred while executing this line: /Users/lov080/Downloads/MLVM/JDK7/langtools/make/build.xml:816: Compile failed; see the compiler error output for details. Total time: 14 seconds The JDK that I using for the compilation is from Stephen Bannasch and dated 2011_01_11: java (JVM) Version: openjdk version "1.7.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.7.0-internal-fastdebug-stephen_2011_01_11_21_45-b00) OpenJDK 64-Bit Server VM (build 20.0-b03-fastdebug, mixed mode) I also get the same errors with the 2011_02_24 build from Stephen. The version of the SDK I am attempting to build is: javac (SDK) Version: changeset: 932:5aeda537bf98 tag: tip user: mcimadamore date: Tue Mar 01 17:48:13 2011 +0000 summary: Fix: wrong subtyping implementation for disjunctive types. Looks like File might have gone missing! Thanks for posting the regular improvements. ? -- Howard. From forax at univ-mlv.fr Fri Mar 4 15:48:10 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 05 Mar 2011 00:48:10 +0100 Subject: Compilation problem In-Reply-To: References: Message-ID: <4D717A3A.1040406@univ-mlv.fr> Package java.nio.files changes in b132. The code of the compiler was updated accordingly. But you use a VM created by Stephen from a workspace which is older than b132. Solutions: - gently ask Stephen to build a new version based on b132 sources. - get a b132, extract package java.nio.files and put it in the boostrap class (and pray that there is no VM changes). R?mi On 03/05/2011 12:37 AM, Howard Lovatt wrote: > Hi, > > I am compiling the latest version of the SDK from the Mercurial > repository and I get the following errors: > > build-bootstrap-javac: > [javac] Compiling 29 source files to > /Users/lov080/Downloads/MLVM/JDK7/langtools/build/bootstrap/classes > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:326: > cannot find symbol > [javac] if (!Files.exists(path)) > [javac] ^ > [javac] symbol: method exists(Path) > [javac] location: class Files > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:341: > cannot find symbol > [javac] if (!Files.exists(packageDir)) > [javac] ^ > [javac] symbol: method exists(Path) > [javac] location: class Files > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:376: > cannot find symbol > [javac] Path name = dir.getFileName(); > [javac] ^ > [javac] symbol: method getFileName() > [javac] location: class Path > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:385: > cannot find symbol > [javac] if (attrs.isRegularFile()&& > kinds.contains(getKind(file.getFileName().toString()))) { > [javac] > ^ > [javac] symbol: method getFileName() > [javac] location: class Path > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:431: > cannot find symbol > [javac] if (Files.exists(f)) > [javac] ^ > [javac] symbol: method exists(Path) > [javac] location: class Files > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:437: > cannot find symbol > [javac] if (Files.exists(file)) > [javac] ^ > [javac] symbol: method exists(Path) > [javac] location: class Files > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:504: > no suitable method found for newFileSystem(Path,) > [javac] fs = FileSystems.newFileSystem(p, null); > [javac] ^ > [javac] method > FileSystems.newFileSystem(FileRef,Map,ClassLoader) is not > applicable > [javac] (actual and formal argument lists differ in length) > [javac] method > FileSystems.newFileSystem(URI,Map,ClassLoader) is not > applicable > [javac] (actual and formal argument lists differ in length) > [javac] method FileSystems.newFileSystem(URI,Map) is > not applicable > [javac] (actual argument Path cannot be converted to URI by > method invocation conversion) > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java:530: > cannot find symbol > [javac] BasicFileAttributes attrs = > Files.readAttributes(path, BasicFileAttributes.class); > [javac] ^ > [javac] symbol: method readAttributes(Path,Class) > [javac] location: class Files > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:155: > cannot find symbol > [javac] return > BaseFileManager.getKind(path.getFileName().toString()); > [javac] ^ > [javac] symbol: method getFileName() > [javac] location: class Path > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:166: > cannot find symbol > [javac] String pn = path.getFileName().toString(); > [javac] ^ > [javac] symbol: method getFileName() > [javac] location: class Path > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:173: > cannot find symbol > [javac] return > path.toRealPath(false).getFileName().toString().equals(sn); > [javac] ^ > [javac] symbol: method getFileName() > [javac] location: class Path > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:202: > cannot find symbol > [javac] return Files.newInputStream(path); > [javac] ^ > [javac] symbol: method newInputStream(Path) > [javac] location: class Files > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:208: > cannot find symbol > [javac] return Files.newOutputStream(path); > [javac] ^ > [javac] symbol: method newOutputStream(Path) > [javac] location: class Files > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:244: > cannot find symbol > [javac] return new > OutputStreamWriter(Files.newOutputStream(path), > fileManager.getEncodingName()); > [javac] ^ > [javac] symbol: method newOutputStream(Path) > [javac] location: class Files > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:250: > cannot find symbol > [javac] return Files.getLastModifiedTime(path).toMillis(); > [javac] ^ > [javac] symbol: method getLastModifiedTime(Path) > [javac] location: class Files > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:259: > cannot find symbol > [javac] Files.delete(path); > [javac] ^ > [javac] symbol: method delete(Path) > [javac] location: class Files > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:268: > cannot find symbol > [javac] return Files.isSameFile(path, other.path); > [javac] ^ > [javac] symbol: method isSameFile(Path,Path) > [javac] location: class Files > [javac] /Users/lov080/Downloads/MLVM/JDK7/langtools/src/share/classes/com/sun/tools/javac/nio/PathFileObject.java:297: > cannot find symbol > [javac] return Files.size(path); > [javac] ^ > [javac] symbol: method size(Path) > [javac] location: class Files > [javac] 18 errors > > BUILD FAILED > /Users/lov080/Downloads/MLVM/JDK7/langtools/make/build.xml:452: The > following error occurred while executing this line: > /Users/lov080/Downloads/MLVM/JDK7/langtools/make/build.xml:816: > Compile failed; see the compiler error output for details. > > Total time: 14 seconds > > > The JDK that I using for the compilation is from Stephen Bannasch and > dated 2011_01_11: > > java (JVM) Version: > openjdk version "1.7.0-internal-fastdebug" > OpenJDK Runtime Environment (build > 1.7.0-internal-fastdebug-stephen_2011_01_11_21_45-b00) > OpenJDK 64-Bit Server VM (build 20.0-b03-fastdebug, mixed mode) > > I also get the same errors with the 2011_02_24 build from Stephen. The > version of the SDK I am attempting to build is: > > javac (SDK) Version: > changeset: 932:5aeda537bf98 > tag: tip > user: mcimadamore > date: Tue Mar 01 17:48:13 2011 +0000 > summary: Fix: wrong subtyping implementation for disjunctive types. > > Looks like File might have gone missing! > > Thanks for posting the regular improvements. > > -- Howard. > From ali.ebrahimi1781 at gmail.com Fri Mar 4 21:30:18 2011 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Sat, 5 Mar 2011 09:00:18 +0330 Subject: Inferring lambda parameter types in an argument position In-Reply-To: References: Message-ID: Hi all, +1, This may be duplicate of this http://mail.openjdk.java.net/pipermail/lambda-dev/2010-October/002488.html Best Regards, Ali Ebrahimi On Fri, Mar 4, 2011 at 10:46 PM, Neal Gafter wrote: > Dear Lambda- > > I'd like the lambda conversion to infer lambda parameter types even when > the > lambda appears in an argument position and the underlying method is > overloaded. > > For example, given > > *interface Mapping > { > Out map(In in); > } > interface IndexedMapping > { > Out map(In in, int index); > } > interface Predicate > { > bool isSatisfied(E e); > } > interface MyList { > MyList map(Mapping f) ...; > MyList map(IndexedMapping f) ...; > MyList filter(Predicate p) ... > } > * > > I would like to be able to write my lambdas with parameter types elided: > * > * > *MyList list = ...;* > *MyList newList = list > .map( #{ x -> new Y(x) } ) > .filter( #{ y -> y.IsFunny() } );* > > This is all modulo syntax. I'd prefer the syntax > > *MyList newList = list > .map( x -> new Y(x) ) > .filter( y -> y.IsFunny() ); > * > > but that is a discussion for another day (just let us know which day). > > Cheers, > Neal > > From neal at gafter.com Fri Mar 4 22:31:21 2011 From: neal at gafter.com (Neal Gafter) Date: Fri, 4 Mar 2011 22:31:21 -0800 Subject: Inferring lambda parameter types in an argument position In-Reply-To: References: Message-ID: I'm aware this is not a new issue. But it is ripe. On Friday, March 4, 2011, Ali Ebrahimi wrote: > Hi all, > +1, > This may be duplicate of this > http://mail.openjdk.java.net/pipermail/lambda-dev/2010-October/002488.html > > Best Regards, > Ali Ebrahimi > > On Fri, Mar 4, 2011 at 10:46 PM, Neal Gafter wrote: > >> Dear Lambda- >> >> I'd like the lambda conversion to infer lambda parameter types even when >> the >> lambda appears in an argument position and the underlying method is >> overloaded. >> >> For example, given >> >> *interface Mapping >> { >> ? ?Out map(In in); >> } >> interface IndexedMapping >> { >> ? ?Out map(In in, int index); >> } >> interface Predicate >> { >> ? ?bool isSatisfied(E e); >> } >> interface MyList { >> ? ? MyList map(Mapping f) ...; >> ? ? MyList map(IndexedMapping f) ...; >> ? ?MyList filter(Predicate p) ... >> } >> * >> >> I would like to be able to write my lambdas with parameter types elided: >> * >> * >> *MyList list = ...;* >> *MyList newList = list >> ? ?.map( #{ x -> new Y(x) } ) >> ? ?.filter( #{ y -> y.IsFunny() } );* >> >> This is all modulo syntax. ?I'd prefer the syntax >> >> *MyList newList = list >> ? ?.map( x -> new Y(x) ) >> ? ?.filter( y -> y.IsFunny() ); >> * >> >> but that is a discussion for another day (just let us know which day). >> >> Cheers, >> Neal >> >> > > From maurizio.cimadamore at oracle.com Sat Mar 5 04:18:13 2011 From: maurizio.cimadamore at oracle.com (maurizio cimadamore) Date: Sat, 05 Mar 2011 12:18:13 +0000 Subject: Inferring lambda parameter types in an argument position In-Reply-To: References: <4D714778.5010602@oracle.com> Message-ID: <4D722A05.8010802@oracle.com> On 04/03/2011 22:18, Neal Gafter wrote: > Maurizio- > > That's great! However, I should say I'm more concerned about the > specification than about the current prototype, because > > 1. The prototype will change, but what we finally get is what we have > to live with; > 2. The implementation needs to agree with the specification, not > merely appear to "do the right thing"; and > 3. Getting the specification right is much harder, as the spec has to > give some reasonable result in *all* cases, not just the ones that > were encountered while developing the prototype. You are absolutely right - the compiler has been proven very helpful to understand the limit of what can be achieved with local type-inference techniques (i.e. problems with chained calls, or exception tyransparency to name a few). All this information will be used to feedback the spec, so that we will end up with something sensible on both sides, also considering the use cases that we have been discussing so far (which I think are very reasonable). > > Also, there are interesting cases around nested lambdas with overload > resolution that the spec should be capable of handling: > > *a.F( x -> x.G( y -> H(x, y) ) )* The above is quite nasty - in general you only will be able to establish members of the type of an unspecified lambda parameter after a type for it has been inferred (which should be done by looking at the expected formal type during overload resolution). Depending on which strategy we decide to support in the spec, 'x.G' might or might not be a typable expression (e.g. part of the problem is that doing overload resolution with partially inferred types could lead to selecting a method that could turn out to be inapplicable when all inference variables have been inferred). The design space is very big - I think the best solution would be to find a resonable compromise between expressiveness and language complexity; speaking of which, all examples submitted in this mailing list and the experiments we are starting to make on collections are surely a valuable resource to drive design of type-inference forward. Maurizio > > That said, I certainly agree that the prototyping effort is helping to > figure out what to specify. > > Cheers, > Neal > > On Fri, Mar 4, 2011 at 12:11 PM, Maurizio Cimadamore > > wrote: > > Hi Neal, > I think we are on the same page here. The current compiler works > *almost* fine - only problem is inference in chained calls (i.e. > chained call to 'filter' in your example) - but we are working on it. > > Maurizio > > > On 04/03/11 19:16, Neal Gafter wrote: > > interface Mapping > { > Out map(In in); > } > interface IndexedMapping > { > Out map(In in, int index); > } > interface Predicate > { > bool isSatisfied(E e); > } > interface MyList { > MyList map(Mapping f) ...; > MyList map(IndexedMapping f) > ...; > MyList filter(Predicate p) ... > } > * > > I would like to be able to write my lambdas with parameter > types elided: > * > * > *MyList list = ...;* > *MyList newList = list > .map( #{ x -> new Y(x) } ) > .filter( #{ y -> y.IsFunny() } );* > > This is all modulo syntax. I'd prefer the syntax > > *MyList newList = list > .map( x -> new Y(x) ) > .filter( y -> y.IsFunny() ); > * > > > From opinali at gmail.com Sat Mar 5 05:23:06 2011 From: opinali at gmail.com (Osvaldo Pinali Doederlein) Date: Sat, 05 Mar 2011 08:23:06 -0500 Subject: Inferring lambda parameter types in an argument position In-Reply-To: <4D722A05.8010802@oracle.com> References: <4D714778.5010602@oracle.com> <4D722A05.8010802@oracle.com> Message-ID: <4D72393A.3080907@gmail.com> On 3/5/2011 7:18 AM, maurizio cimadamore wrote: > or exception tyransparency :-) just a typo, or a Freudian slip? A+ Osvaldo From maurizio.cimadamore at oracle.com Sat Mar 5 09:57:16 2011 From: maurizio.cimadamore at oracle.com (maurizio cimadamore) Date: Sat, 05 Mar 2011 17:57:16 +0000 Subject: Inferring lambda parameter types in an argument position In-Reply-To: <4D72393A.3080907@gmail.com> References: <4D714778.5010602@oracle.com> <4D722A05.8010802@oracle.com> <4D72393A.3080907@gmail.com> Message-ID: <4D72797C.7090602@oracle.com> On 05/03/2011 13:23, Osvaldo Pinali Doederlein wrote: > On 3/5/2011 7:18 AM, maurizio cimadamore wrote: >> or exception tyransparency > :-) just a typo, or a Freudian slip? Damn you got me :-) Maurizio > A+ > Osvaldo > From neal at gafter.com Sat Mar 5 12:23:55 2011 From: neal at gafter.com (Neal Gafter) Date: Sat, 5 Mar 2011 12:23:55 -0800 Subject: Inferring lambda parameter types in an argument position In-Reply-To: <4D722A05.8010802@oracle.com> References: <4D714778.5010602@oracle.com> <4D722A05.8010802@oracle.com> Message-ID: On Sat, Mar 5, 2011 at 4:18 AM, maurizio cimadamore < maurizio.cimadamore at oracle.com> wrote: > *a.F( x -> x.G( y -> H(x, y) ) )* > The above is quite nasty - in general you only will be able to establish > members of the type of an unspecified lambda parameter after a type for it > has been inferred (which should be done by looking at the expected formal > type during overload resolution). Depending on which strategy we decide to > support in the spec, 'x.G' might or might not be a typable expression (e.g. > part of the problem is that doing overload resolution with partially > inferred types could lead to selecting a method that could turn out to be > inapplicable when all inference variables have been inferred). The design > space is very big - I think the best solution would be to find a resonable > compromise between expressiveness and language complexity; speaking of > which, all examples submitted in this mailing list and the experiments we > are starting to make on collections are surely a valuable resource to drive > design of type-inference forward. > I would like to point out that C# handles such cases quite well, even though its specification for type inference is fairly simple. It might be valuable to learn the extent to which C#'s techniques could be applied to Java. From isidore at setgame.com Sat Mar 5 14:17:18 2011 From: isidore at setgame.com (Llewellyn Falco) Date: Sat, 5 Mar 2011 14:17:18 -0800 Subject: Inferring lambda parameter types in an argument position In-Reply-To: References: <4D714778.5010602@oracle.com> <4D722A05.8010802@oracle.com> Message-ID: I'd also like to pipe in regarding the naming. Since we won't have extension methods, and therefor can't change the names of the methods easily, I would really like to suggest we use the mapping to SQL syntax. It's much easier to understand and consume. MyList newList = list .map( #{ x -> new Y(x) } ) .filter( #{ y -> y.IsFunny() } ); MyList newList = list .select( #{ x -> new Y(x) } ) .where( #{ y -> y.IsFunny() } ); select, where, groupby, orderby we are already familiar with the name and concept. Llewellyn Falco From forax at univ-mlv.fr Sun Mar 6 07:21:03 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 06 Mar 2011 16:21:03 +0100 Subject: Inferring lambda parameter types in an argument position In-Reply-To: References: <4D714778.5010602@oracle.com> <4D722A05.8010802@oracle.com> Message-ID: <4D73A65F.2090501@univ-mlv.fr> On 03/05/2011 11:17 PM, Llewellyn Falco wrote: > I'd also like to pipe in regarding the naming. > Since we won't have extension methods, and therefor can't change the names > of the methods easily, I would really like to suggest we use the mapping to > SQL syntax. It's much easier to understand and consume. > > MyList newList = list > .map( #{ x -> new Y(x) } ) > .filter( #{ y -> y.IsFunny() } ); > > MyList newList = list > .select( #{ x -> new Y(x) } ) > .where( #{ y -> y.IsFunny() } ); > > select, where, groupby, orderby > > we are already familiar with the name and concept. > > > Llewellyn Falco > C# has its own view of what a SQL select and where clause means. Ruby, Python even Objective-C all use map, filter, reduce. R?mi From brian.goetz at oracle.com Sun Mar 6 09:05:34 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 6 Mar 2011 09:05:34 -0800 Subject: Inferring lambda parameter types in an argument position Message-ID: On Mar 5, 2011, at 2:17 PM, Llewellyn Falco wrote: > I'd also like to pipe in regarding the naming. > Since we won't have extension methods Um, what? Where did you get the idea that we're not doing extension methods? From forax at univ-mlv.fr Sun Mar 6 09:52:40 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 06 Mar 2011 18:52:40 +0100 Subject: Inferring lambda parameter types in an argument position In-Reply-To: References: Message-ID: <4D73C9E8.809@univ-mlv.fr> On 03/06/2011 06:05 PM, Brian Goetz wrote: > On Mar 5, 2011, at 2:17 PM, Llewellyn Falco wrote: > >> I'd also like to pipe in regarding the naming. >> Since we won't have extension methods > Um, what? Where did you get the idea that we're not doing extension methods? > I think he wants to write: since we won't have C# extension methods. R?mi From maurizio.cimadamore at oracle.com Mon Mar 7 03:51:53 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 07 Mar 2011 11:51:53 +0000 Subject: hg: lambda/lambda/langtools: Fixed SAM conversion for corner case involving abstract classes implementing ''target'' abstract method. Message-ID: <20110307115200.55AB147EE9@hg.openjdk.java.net> Changeset: c80ead80fcfd Author: mcimadamore Date: 2011-03-07 11:50 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c80ead80fcfd Fixed SAM conversion for corner case involving abstract classes implementing ''target'' abstract method. This is just for completeness, given that abstract classes support in SAM conversion has been dropped. ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/LambdaConv15.java From maurizio.cimadamore at oracle.com Mon Mar 7 05:55:45 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 07 Mar 2011 13:55:45 +0000 Subject: hg: lambda/lambda/langtools: Types.findSAM throws NPE when target type of SAM conversion is an interface inheriting non-overriding members. Message-ID: <20110307135548.1147447EF9@hg.openjdk.java.net> Changeset: 1623ce0ec047 Author: mcimadamore Date: 2011-03-07 13:54 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/1623ce0ec047 Types.findSAM throws NPE when target type of SAM conversion is an interface inheriting non-overriding members. ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/BadConv03.java + test/tools/javac/lambda/BadConv03.out From mike.duigou at oracle.com Mon Mar 7 15:57:47 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 7 Mar 2011 15:57:47 -0800 Subject: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] In-Reply-To: References: Message-ID: On Feb 23 2011, at 11:54 , lambda-dev-request at openjdk.java.net wrote: > From: Neal Gafter > Date: February 23, 2011 07:49:49 PST > To: brian.goetz at oracle.com > Cc: lambda-dev at openjdk.java.net > Subject: Re: hg: lambda/collections/jdk: 2 new changesets > > > Brian- > > The "reduce" (left fold) method should not require the result type to be the > same as the collection's element type. > > Cheers, > Neal Hi Neal; That was my reaction as well but Brian convinced me that having a different result and initial type was just a conflation of map with reduce. After thinking about it for a while I've been unable to come up with any cases that couldn't be satisfied by a map step (which may merely do type conversion) before the reduce step. Is there another reason to have reduce return a different type than the element? Mike From robert.field at oracle.com Mon Mar 7 17:32:12 2011 From: robert.field at oracle.com (robert.field at oracle.com) Date: Tue, 08 Mar 2011 01:32:12 +0000 Subject: hg: lambda/defender-prototype: 2 new changesets Message-ID: <20110308013212.4F27147F61@hg.openjdk.java.net> Changeset: 6e9be31f0f67 Author: Robert Field Date: 2011-03-07 17:27 -0800 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/6e9be31f0f67 Introduce new algorithm corresponding to current FD; Make it default; Change test so that defaults pass-through interface abstract methods ! build.xml ! src/jsr335/agent/Agent.java ! src/jsr335/agent/batch/Main.java + src/jsr335/agent/top/AbstractFDClassModel.java ! src/jsr335/agent/top/ClassModel.java + src/jsr335/agent/top/DelegatingWeaveAnalyzer.java + src/jsr335/agent/top/FDci2f4ClassModel.java + src/jsr335/agent/top/FDci2f4Factory.java ! src/jsr335/agent/top/SimpleClassModel.java ! src/jsr335/agent/top/SimpleFactory.java - src/jsr335/agent/top/SimpleWeaveAnalyzer.java ! test/jsr335/agent/junit/ReabstractionTest.java Changeset: f06ffed90e62 Author: Robert Field Date: 2011-03-07 17:31 -0800 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/f06ffed90e62 merge CovariantOverrideTest with new algorithm From robert.field at oracle.com Mon Mar 7 17:46:40 2011 From: robert.field at oracle.com (robert.field at oracle.com) Date: Tue, 08 Mar 2011 01:46:40 +0000 Subject: hg: lambda/defender-prototype: add corresponding FD Message-ID: <20110308014640.865C147F67@hg.openjdk.java.net> Changeset: 679e8e9b4c9b Author: Robert Field Date: 2011-03-07 17:47 -0800 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/679e8e9b4c9b add corresponding FD + doc/featherweight-defenders.pdf From neal at gafter.com Mon Mar 7 18:30:21 2011 From: neal at gafter.com (Neal Gafter) Date: Mon, 7 Mar 2011 18:30:21 -0800 Subject: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 3:57 PM, Mike Duigou wrote: > > From: Neal Gafter > > Date: February 23, 2011 07:49:49 PST > > > > The "reduce" (left fold) method should not require the result type to be > the > > same as the collection's element type. > > That was my reaction as well but Brian convinced me that having a different > result and initial type was just a conflation of map with reduce. After > thinking about it for a while I've been unable to come up with any cases > that couldn't be satisfied by a map step (which may merely do type > conversion) before the reduce step. Is there another reason to have reduce > return a different type than the element? > I should start by pointing out that the map/reduce formality popularized by Google has little to do with this API, as Google's "reduce" operation produces a collection of results. To avoid confusion I will call Lambda's operation "fold". To answer your question: First, it is strictly more expressive, as the fold function with separate input and result types has more information to work with than either the mapping function or the fold function in separate map/fold steps (though you can get the same effect by introducing extra mapping steps to preserve the needed data in intermediate types). Second, the "initial" value in the fold operation doesn't provide much value if the fold operation is homogeneously typed. Finally, there is a great deal of experience with these kinds of bulk data APIs in the functional programming community, who after long experience have come to prefer the version in which the source and destination types may differ. It would be a shame to ignore their experience and repeat mistakes of the distant past. See also > and > or, for some simple examples, >. Being composed of experts, I expect that the Project Lambda JSR expert group has members who are well versed in these techniques. Cheers, Neal From robert.field at oracle.com Mon Mar 7 23:14:21 2011 From: robert.field at oracle.com (robert.field at oracle.com) Date: Tue, 08 Mar 2011 07:14:21 +0000 Subject: hg: lambda/defender-prototype: Reorganize FD; Add FD source; Line-up agent source to version rather than named FDs Message-ID: <20110308071421.640E247F92@hg.openjdk.java.net> Changeset: 403d329d26ab Author: Robert Field Date: 2011-03-07 23:15 -0800 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/403d329d26ab Reorganize FD; Add FD source; Line-up agent source to version rather than named FDs ! doc/featherweight-defenders.pdf + doc/featherweight-defenders.tex ! src/jsr335/agent/Agent.java ! src/jsr335/agent/batch/Main.java + src/jsr335/agent/top/FDClassModel.java + src/jsr335/agent/top/FDFactory.java - src/jsr335/agent/top/FDci2f4ClassModel.java - src/jsr335/agent/top/FDci2f4Factory.java From lk at teamten.com Tue Mar 8 00:37:35 2011 From: lk at teamten.com (Lawrence Kesteloot) Date: Tue, 8 Mar 2011 00:37:35 -0800 Subject: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 6:30 PM, Neal Gafter wrote: > It would be a shame to ignore [the functional programming community's] experience > and repeat mistakes of the distant past. Their mistake of the distant past was to use fold-left in the first place. > for some simple examples, foldLeft Examples" I assert that every single one of those examples would be more clearly (if more verbosely) expressed as a for-loop. (I tried this myself and it's striking how much clearer the for-loop is, and often more efficient.) I can genuinely see why computer science theorists love fold-left, but it doesn't belong in any code that will later be read by a human. Java should follow the example of Python 3000 and remove fold-left from the API. > Being composed of experts, I expect that the Project Lambda JSR expert group > has members who are well versed in these techniques. I'm hoping for exactly the same thing. Lawrence From john at milsson.nu Tue Mar 8 02:16:15 2011 From: john at milsson.nu (John Nilsson) Date: Tue, 8 Mar 2011 11:16:15 +0100 Subject: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] In-Reply-To: References: Message-ID: On Tue, Mar 8, 2011 at 9:37 AM, Lawrence Kesteloot wrote: > I assert that every single one of those examples would be more clearly > (if more verbosely) expressed as a for-loop. You might be correct. But two instinctive retorts: a) A fold as IoC lets you handle concerns such as resource managment on the other end of the call. F.ex. iterating over an open resultset from a DB. b) A fold is clearer for point free declarations. And generally more composable Ex: sum = fold 0 + BR, John From jim at pentastich.org Tue Mar 8 05:31:48 2011 From: jim at pentastich.org (Jim Mayer) Date: Tue, 8 Mar 2011 08:31:48 -0500 Subject: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] In-Reply-To: References: Message-ID: I would also like to see the result type to be the same as the collection's element type. While I think it's true that one can combine map and a uniform fold function to get a similar result (especially if one introduces intermediate objects in the map (e.g., 'Pair')), I think it also results in more verbose, less transparent, code. Compare the following (I'm not up on the syntax of the proposed collections changes, so please bear with me): // I like this one long product(List list) { return list.reduce(0L, #{ sum, x -> sum * x }); } or // I can tolerate this one long product(List list) { return Collections.reduce(list, 0L, #{ sum, x -> sum * x }); } to // I can tolerate this one long product(List list) { return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> sum * x}); } or // This one makes me gag long product(List list) { return Collections.reduce(Collections.map(list, #{x -> (long) x}), 0L, #{sum, x -> sum * x}); } More fundamentally, operators like 'reduce', 'foldLeft', whatever, seem mathematical in nature. Most mathematical notations talk about 'integers' or 'numbers' (or 'groups', for that matter). They don't usually talk about '32 bit integers' or '64 bit integers'. Java numbers, on the other hand, are fixed size and we can't ignore that. To me, the first example above clearly expresses the mathematical concept of 'product' while respecting Java's primitive types. In the second, though, the type conversion implemented by the 'map' seems extraneous to the 'product' concept. While I don't share Lawrence Kesteloot's belief that "I can genuinely see why computer science theorists love fold-left, but it doesn't belong in any code that will later be read by a human", I do object to deeply nested compositions of map/reduce like operations. -- Jim The second On Mon, Mar 7, 2011 at 9:30 PM, Neal Gafter wrote: > On Mon, Mar 7, 2011 at 3:57 PM, Mike Duigou > wrote: > > > > From: Neal Gafter > > > Date: February 23, 2011 07:49:49 PST > > > > > > The "reduce" (left fold) method should not require the result type to > be > > the > > > same as the collection's element type. > > > > That was my reaction as well but Brian convinced me that having a > different > > result and initial type was just a conflation of map with reduce. After > > thinking about it for a while I've been unable to come up with any cases > > that couldn't be satisfied by a map step (which may merely do type > > conversion) before the reduce step. Is there another reason to have > reduce > > return a different type than the element? > > > > I should start by pointing out that the map/reduce formality popularized by > Google has little to do with this API, as Google's "reduce" operation > produces a collection of results. To avoid confusion I will call Lambda's > operation "fold". > > To answer your question: > > First, it is strictly more expressive, as the fold function with separate > input and result types has more information to work with than either the > mapping function or the fold function in separate map/fold steps (though > you > can get the same effect by introducing extra mapping steps to preserve the > needed data in intermediate types). Second, the "initial" value in the > fold > operation doesn't provide much value if the fold operation is homogeneously > typed. > > Finally, there is a great deal of experience with these kinds of bulk data > APIs in the functional programming community, who after long experience > have > come to prefer the version in which the source and destination types may > differ. It would be a shame to ignore their experience and repeat mistakes > of the distant past. See also universality and expressiveness of fold" from the Journal of Functional > Programming (9 (4)) > and foldLeft operation< > http://functionaljava.googlecode.com/svn/artifacts/3.0/javadoc/fj/data/List.html#foldLeft%28fj.F2,%20B%29 > >> > or, for some simple examples, foldLeft Examples"< > http://oldfashionedsoftware.com/2009/07/30/lots-and-lots-of-foldleft-examples/ > > > >. > > Being composed of experts, I expect that the Project Lambda JSR expert > group > has members who are well versed in these techniques. > > Cheers, > Neal > > From forax at univ-mlv.fr Tue Mar 8 05:43:49 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 08 Mar 2011 14:43:49 +0100 Subject: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] In-Reply-To: References: Message-ID: <4D763295.7000708@univ-mlv.fr> Le 08/03/2011 14:31, Jim Mayer a ?crit : > // I can tolerate this one > long product(List list) { > return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> sum * x}); > } I prefer this one: long product(List list) { return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, x -> sum * x}); } lazy() means, don't do map directly, but wait and do map and reduce in one iteration. R?mi From alessiostalla at gmail.com Tue Mar 8 07:41:57 2011 From: alessiostalla at gmail.com (Alessio Stalla) Date: Tue, 8 Mar 2011 16:41:57 +0100 Subject: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] In-Reply-To: <4D763295.7000708@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> Message-ID: On Tue, Mar 8, 2011 at 2:43 PM, R?mi Forax wrote: > ?Le 08/03/2011 14:31, Jim Mayer a ?crit : >> // I can tolerate this one >> ? ? ?long product(List ?list) { >> ? ? ? ?return list.map(#{x -> ?(long) x}).reduce(0L, #{sum, x -> ?sum * x}); >> ? ? ?} > > I prefer this one: > > ? long product(List ?list) { > ? ? ? return list.lazy().map(#{x -> ?(long) x}).reduce(0L, #{sum, x -> ?sum * x}); > ? } > > lazy() means, don't do map directly, but wait and do map and reduce in > one iteration. Nice! But still, I don't see a compelling reason to force users to keep map & reduce strictly distinct operations. It might be cleaner on a theoretical point of view, but what does it buy in practice to have the result type match the collection's element type? If for whatever reason you want to make map and reduce appear in source as separate steps, you can. Also, by forcing the types to be the same you require an explicit map step even in the (imho) important use case where the initial value's type is a supertype of the collection's element type and the operation returns the supertype. Silly example (assuming a Number class capable of generic arithmetic): Number avg(Collection data) { return data.reduce(Number.ZERO, #{ sum, x -> sum.add(x) }).div(data.size()); } data could hold integers, fractions, complexes... you'd need an explicit map step just to upcast to Number (which is not even a conversion like in the (long) example), else the types won't match. Just my .02 Alessio From brian.goetz at oracle.com Tue Mar 8 09:23:07 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 08 Mar 2011 12:23:07 -0500 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: <4D763295.7000708@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> Message-ID: <4D7665FB.5070209@oracle.com> Since people are already discussing this based on an experimental checkin, let me outline the big picture plan here. The general idea is to add functional-like operations to collections -- filter, map, reduce, apply. I see three sensible modes, with explicit choices of which you get. 1. Serial / Eager. This is the straight collections-with-functional-style mode, and some samples have already been checked in as proof of concept. Operations on collections yield new collections, and you can chain the calls. It values ease of use over performance (no new concepts like laziness), but the performance model is still highly predictable. You get things like Collection fooAbles = things.filter( #{ t -> t.isFoo() }); or, with method references: Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty You can also chain calls together, though you pay a (predictable) performance cost of intermediate collections, which for small collections is unlikely to matter: maxFooWeight = things.filter(#Thing.isFoo) .map(#Thing.getWeight) .max(); The benefit here is concision and clarity. The cost is some performance, but maybe not so much that people freak out. If people care, they move to the next model, which is: 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be chosen later, Remi used "lazy" in his example.) To transfer between "eager world" and "lazy world", you use conversion methods (toStream / toCollection). A typical call chain probably looks like: collection.toStream / op / op / op / {toCollection,reduce,apply} so the above example becomes maxFooWeight = things.asStream() .filter(#Thing.isFoo) .map(#Thing.getWeight) .max(); The return type of Collection.filter is different from the return type of Stream.filter, so the choice and performance costs are reflected in the static type system. This avoids the cost of the intermediate collections, but is still serial. If you care about that, you move up to the next model, which is: 3. Parallel / Lazy. Here, the primary abstraction is something like ParallelStream or ParallelIterable. Let's call it ParallelFoo to avoid bikeshedding for the moment. Now, the code looks like: maxFooWeight = things.asParallelFoo() .filter(#Thing.isFoo) .map(#Thing.getWeight) .max(); Again, the return type of ParallelFoo.filter is different from Stream.filter or Collection.filter, so again the choice is reflected in the static type system. But you don't have to rewrite your code. The beauty here is twofold: - The base model (serial/eager) is easy to understand and natural to use as a way of expressing what the programmer wants to do, and attractive enough to stand on its own -- just a little slow with big collections. - Switching between execution models is mostly a matter of adding an explicit conversion or two in the call chain, as the models are similar enough that the rest of the code should still work (and even mean the same thing.) On 3/8/2011 8:43 AM, R?mi Forax wrote: > Le 08/03/2011 14:31, Jim Mayer a ?crit : >> // I can tolerate this one >> long product(List list) { >> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> sum * x}); >> } > > I prefer this one: > > long product(List list) { > return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, x -> sum * x}); > } > > lazy() means, don't do map directly, but wait and do map and reduce in > one iteration. > > R?mi > > From lk at teamten.com Tue Mar 8 10:17:03 2011 From: lk at teamten.com (Lawrence Kesteloot) Date: Tue, 8 Mar 2011 10:17:03 -0800 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: <4D7665FB.5070209@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: Very nice. I'm curious about the exception declaration in the streaming model. In your serial/lazy example below: > ? ? ?maxFooWeight = things.asStream() > ? ? ? ? ? ? ? ? ? ? ? ? ? .filter(#Thing.isFoo) > ? ? ? ? ? ? ? ? ? ? ? ? ? .map(#Thing.getWeight) > ? ? ? ? ? ? ? ? ? ? ? ? ? .max(); max() can throw the union of the exceptions thrown by Thing.isFoo and Thing.getWeight. What does the declaration of map() look like? It's part of a type that is parameterized on Thing.isFoo's exceptions and must add, in its return value, the exceptions that Thing.getWeight throws. Also, would you consider adding list comprehension syntax, which would de-sugar to the serial/eager version: weights = [thing.getWeight() for Thing thing : things if thing.isFoo()] or the lazy version: weights = (thing.getWeight() for Thing thing : things if thing.isFoo()) Lawrence On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz wrote: > Since people are already discussing this based on an experimental > checkin, let me outline the big picture plan here. > > The general idea is to add functional-like operations to collections -- > filter, map, reduce, apply. > > I see three sensible modes, with explicit choices of which you get. > > 1. ?Serial / Eager. ?This is the straight > collections-with-functional-style mode, and some samples have already > been checked in as proof of concept. ?Operations on collections yield > new collections, and you can chain the calls. ?It values ease of use > over performance (no new concepts like laziness), but the performance > model is still highly predictable. ?You get things like > > ? ? ?Collection fooAbles = things.filter( #{ t -> t.isFoo() }); > > or, with method references: > > ? ? ?Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty > > You can also chain calls together, though you pay a (predictable) > performance cost of intermediate collections, which for small > collections is unlikely to matter: > > ? ? ?maxFooWeight = things.filter(#Thing.isFoo) > ? ? ? ? ? ? ? ? ? ? ? ? ? .map(#Thing.getWeight) > ? ? ? ? ? ? ? ? ? ? ? ? ? .max(); > > The benefit here is concision and clarity. ?The cost is some > performance, but maybe not so much that people freak out. ?If people > care, they move to the next model, which is: > > 2. ?Serial / Lazy. ?Here, the primary abstraction is Stream (name to be > chosen later, Remi used "lazy" in his example.) ?To transfer between > "eager world" and "lazy world", you use conversion methods (toStream / > toCollection). ?A typical call chain probably looks like: > ? collection.toStream / op / op / op / {toCollection,reduce,apply} > > so the above example becomes > > ? ? ?maxFooWeight = things.asStream() > ? ? ? ? ? ? ? ? ? ? ? ? ? .filter(#Thing.isFoo) > ? ? ? ? ? ? ? ? ? ? ? ? ? .map(#Thing.getWeight) > ? ? ? ? ? ? ? ? ? ? ? ? ? .max(); > > The return type of Collection.filter is different from the return type > of Stream.filter, so the choice and performance costs are reflected in > the static type system. ?This avoids the cost of the intermediate > collections, but is still serial. ?If you care about that, you move up > to the next model, which is: > > 3. ?Parallel / Lazy. ?Here, the primary abstraction is something like > ParallelStream or ParallelIterable. ?Let's call it ParallelFoo to avoid > bikeshedding for the moment. ?Now, the code looks like: > > ? ? ?maxFooWeight = things.asParallelFoo() > ? ? ? ? ? ? ? ? ? ? ? ? ? .filter(#Thing.isFoo) > ? ? ? ? ? ? ? ? ? ? ? ? ? .map(#Thing.getWeight) > ? ? ? ? ? ? ? ? ? ? ? ? ? .max(); > > Again, the return type of ParallelFoo.filter is different from > Stream.filter or Collection.filter, so again the choice is reflected in > the static type system. ?But you don't have to rewrite your code. > > The beauty here is twofold: > > ?- The base model (serial/eager) is easy to understand and natural to > use as a way of expressing what the programmer wants to do, and > attractive enough to stand on its own -- just a little slow with big > collections. > ?- Switching between execution models is mostly a matter of adding an > explicit conversion or two in the call chain, as the models are similar > enough that the rest of the code should still work (and even mean the > same thing.) > > > On 3/8/2011 8:43 AM, R?mi Forax wrote: >> ? ?Le 08/03/2011 14:31, Jim Mayer a ?crit : >>> // I can tolerate this one >>> ? ? ? long product(List ? list) { >>> ? ? ? ? return list.map(#{x -> ? (long) x}).reduce(0L, #{sum, x -> ? sum * x}); >>> ? ? ? } >> >> I prefer this one: >> >> ? ? long product(List ? list) { >> ? ? ? ? return list.lazy().map(#{x -> ? (long) x}).reduce(0L, #{sum, x -> ? sum * x}); >> ? ? } >> >> lazy() means, don't do map directly, but wait and do map and reduce in >> one iteration. >> >> R?mi >> >> > > From brian.goetz at oracle.com Tue Mar 8 10:36:48 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 08 Mar 2011 13:36:48 -0500 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: <4D767740.7050802@oracle.com> > Very nice. I'm curious about the exception declaration in the > streaming model. This is an open issue. There is an outline for Exception Transparency linked from the latest State of the Lambda that outlines one possible approach which would play nicely with checked exceptions, at the cost of some complexity (in the form of more pointy-bracket craziness (though hopefully mostly inferred by the compiler)). An alternative that some have suggested is to define the standard SAM types to throw nothing, and let lambdas use unchecked exceptions. (The difference between the two is the age-old checked-vs-unchecked exceptions debate.) Both are credible alternatives; most filter/map/reduce lambdas will not throw checked exceptions (though forEach lambda arguments might well, since that relies on side-effects to do anything.) Stay tuned. > Also, would you consider adding list comprehension syntax, which would > de-sugar to the serial/eager version: I'll be honest: no chance of this for Java 8. And not on the radar for after that, either. Our approach to language evolution here is to add the features needed to support library evolution. From forax at univ-mlv.fr Tue Mar 8 11:42:20 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 08 Mar 2011 20:42:20 +0100 Subject: Design for collections upgrades In-Reply-To: <4D7665FB.5070209@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: <4D76869C.7010203@univ-mlv.fr> List things = ... Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty Not that pretty because filter have to create a new collection and there is no way to do that apart hard coding a new ArrayList somewhere. It's better in my opinion to have a filterTo that takes a collection as argument. Collection fooAbles = things.filterTo(#Thing.isFoo, new HashSet<>()); R?mi On 03/08/2011 06:23 PM, Brian Goetz wrote: > Since people are already discussing this based on an experimental > checkin, let me outline the big picture plan here. > > The general idea is to add functional-like operations to collections -- > filter, map, reduce, apply. > > I see three sensible modes, with explicit choices of which you get. > > 1. Serial / Eager. This is the straight > collections-with-functional-style mode, and some samples have already > been checked in as proof of concept. Operations on collections yield > new collections, and you can chain the calls. It values ease of use > over performance (no new concepts like laziness), but the performance > model is still highly predictable. You get things like > > Collection fooAbles = things.filter( #{ t -> t.isFoo() }); > > or, with method references: > > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty > > You can also chain calls together, though you pay a (predictable) > performance cost of intermediate collections, which for small > collections is unlikely to matter: > > maxFooWeight = things.filter(#Thing.isFoo) > .map(#Thing.getWeight) > .max(); > > The benefit here is concision and clarity. The cost is some > performance, but maybe not so much that people freak out. If people > care, they move to the next model, which is: > > 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be > chosen later, Remi used "lazy" in his example.) To transfer between > "eager world" and "lazy world", you use conversion methods (toStream / > toCollection). A typical call chain probably looks like: > collection.toStream / op / op / op / {toCollection,reduce,apply} > > so the above example becomes > > maxFooWeight = things.asStream() > .filter(#Thing.isFoo) > .map(#Thing.getWeight) > .max(); > > The return type of Collection.filter is different from the return type > of Stream.filter, so the choice and performance costs are reflected in > the static type system. This avoids the cost of the intermediate > collections, but is still serial. If you care about that, you move up > to the next model, which is: > > 3. Parallel / Lazy. Here, the primary abstraction is something like > ParallelStream or ParallelIterable. Let's call it ParallelFoo to avoid > bikeshedding for the moment. Now, the code looks like: > > maxFooWeight = things.asParallelFoo() > .filter(#Thing.isFoo) > .map(#Thing.getWeight) > .max(); > > Again, the return type of ParallelFoo.filter is different from > Stream.filter or Collection.filter, so again the choice is reflected in > the static type system. But you don't have to rewrite your code. > > The beauty here is twofold: > > - The base model (serial/eager) is easy to understand and natural to > use as a way of expressing what the programmer wants to do, and > attractive enough to stand on its own -- just a little slow with big > collections. > - Switching between execution models is mostly a matter of adding an > explicit conversion or two in the call chain, as the models are similar > enough that the rest of the code should still work (and even mean the > same thing.) > > > On 3/8/2011 8:43 AM, R?mi Forax wrote: >> Le 08/03/2011 14:31, Jim Mayer a ?crit : >>> // I can tolerate this one >>> long product(List list) { >>> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> sum * x}); >>> } >> I prefer this one: >> >> long product(List list) { >> return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, x -> sum * x}); >> } >> >> lazy() means, don't do map directly, but wait and do map and reduce in >> one iteration. >> >> R?mi >> >> From sam at sampullara.com Tue Mar 8 11:54:25 2011 From: sam at sampullara.com (Sam Pullara) Date: Tue, 8 Mar 2011 11:54:25 -0800 Subject: Design for collections upgrades In-Reply-To: <4D76869C.7010203@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> Message-ID: <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> Or just overload filter with a second argument that is the collection you would like to add to. What is nice about the lazy collections is that you don't need to generate intermediate collections at all and can much more efficiently chain them. Perhaps make them all lazy and require a .to() at the end if you want a Collection vs a Stream? > Collection fooAbles = things.filter(#Thing.isFoo).to(new HashSet<>()); Sam On Mar 8, 2011, at 11:42 AM, R?mi Forax wrote: > > List things = ... > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty > > > Not that pretty because filter have to create a new collection and > there is no way to do that apart hard coding a new ArrayList somewhere. > > It's better in my opinion to have a filterTo that takes a collection > as argument. > > Collection fooAbles = things.filterTo(#Thing.isFoo, new HashSet<>()); > > > R?mi > > On 03/08/2011 06:23 PM, Brian Goetz wrote: >> Since people are already discussing this based on an experimental >> checkin, let me outline the big picture plan here. >> >> The general idea is to add functional-like operations to collections -- >> filter, map, reduce, apply. >> >> I see three sensible modes, with explicit choices of which you get. >> >> 1. Serial / Eager. This is the straight >> collections-with-functional-style mode, and some samples have already >> been checked in as proof of concept. Operations on collections yield >> new collections, and you can chain the calls. It values ease of use >> over performance (no new concepts like laziness), but the performance >> model is still highly predictable. You get things like >> >> Collection fooAbles = things.filter( #{ t -> t.isFoo() }); >> >> or, with method references: >> >> Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty >> >> You can also chain calls together, though you pay a (predictable) >> performance cost of intermediate collections, which for small >> collections is unlikely to matter: >> >> maxFooWeight = things.filter(#Thing.isFoo) >> .map(#Thing.getWeight) >> .max(); >> >> The benefit here is concision and clarity. The cost is some >> performance, but maybe not so much that people freak out. If people >> care, they move to the next model, which is: >> >> 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be >> chosen later, Remi used "lazy" in his example.) To transfer between >> "eager world" and "lazy world", you use conversion methods (toStream / >> toCollection). A typical call chain probably looks like: >> collection.toStream / op / op / op / {toCollection,reduce,apply} >> >> so the above example becomes >> >> maxFooWeight = things.asStream() >> .filter(#Thing.isFoo) >> .map(#Thing.getWeight) >> .max(); >> >> The return type of Collection.filter is different from the return type >> of Stream.filter, so the choice and performance costs are reflected in >> the static type system. This avoids the cost of the intermediate >> collections, but is still serial. If you care about that, you move up >> to the next model, which is: >> >> 3. Parallel / Lazy. Here, the primary abstraction is something like >> ParallelStream or ParallelIterable. Let's call it ParallelFoo to avoid >> bikeshedding for the moment. Now, the code looks like: >> >> maxFooWeight = things.asParallelFoo() >> .filter(#Thing.isFoo) >> .map(#Thing.getWeight) >> .max(); >> >> Again, the return type of ParallelFoo.filter is different from >> Stream.filter or Collection.filter, so again the choice is reflected in >> the static type system. But you don't have to rewrite your code. >> >> The beauty here is twofold: >> >> - The base model (serial/eager) is easy to understand and natural to >> use as a way of expressing what the programmer wants to do, and >> attractive enough to stand on its own -- just a little slow with big >> collections. >> - Switching between execution models is mostly a matter of adding an >> explicit conversion or two in the call chain, as the models are similar >> enough that the rest of the code should still work (and even mean the >> same thing.) >> >> >> On 3/8/2011 8:43 AM, R?mi Forax wrote: >>> Le 08/03/2011 14:31, Jim Mayer a ?crit : >>>> // I can tolerate this one >>>> long product(List list) { >>>> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> sum * x}); >>>> } >>> I prefer this one: >>> >>> long product(List list) { >>> return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, x -> sum * x}); >>> } >>> >>> lazy() means, don't do map directly, but wait and do map and reduce in >>> one iteration. >>> >>> R?mi >>> >>> > > From brian.goetz at oracle.com Tue Mar 8 12:27:36 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 08 Mar 2011 15:27:36 -0500 Subject: Design for collections upgrades In-Reply-To: <4D76869C.7010203@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> Message-ID: <4D769138.8020707@oracle.com> > List things = ... > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty > > Not that pretty because filter have to create a new collection and > there is no way to do that apart hard coding a new ArrayList somewhere. > > It's better in my opinion to have a filterTo that takes a collection > as argument. > > Collection fooAbles = things.filterTo(#Thing.isFoo, new HashSet<>()); This works just fine when there's one operation in the pipeline, but starts to get clunky when the pipeline has multiple steps and you are explicitly specifying the "new ArrayList<>()" a bunch of times. On the other hand, this works much better in the serial/lazy case, since the only place you need to choose a collection type is (typically) at the end of the pipeline: fooableWeights = foos.toStream() .filter(#Thing.isFoo) .map(#Thing.getWeight) .toCollection(new ArrayList<>()); and we should definitely do this for the stream case. From brian.goetz at oracle.com Tue Mar 8 12:28:44 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 08 Mar 2011 15:28:44 -0500 Subject: Design for collections upgrades In-Reply-To: <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> Message-ID: <4D76917C.2010205@oracle.com> On 3/8/2011 2:54 PM, Sam Pullara wrote: > Or just overload filter with a second argument that is the collection > you would like to add to. What is nice about the lazy collections is > that you don't need to generate intermediate collections at all and > can much more efficiently chain them. Perhaps make them all lazy and > require a .to() at the end if you want a Collection vs a Stream? The nice thing about the explicit option is that it supports two different use cases -- "construct me a new collection" (functional composition) and "add them to an existing collection" (union operations). From cgdecker at gmail.com Tue Mar 8 12:29:52 2011 From: cgdecker at gmail.com (Colin Decker) Date: Tue, 8 Mar 2011 15:29:52 -0500 Subject: Design for collections upgrades In-Reply-To: <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> Message-ID: This would be my preference. Make everything that doesn't need to actually iterate lazy by default and do copying at the end if necessary. -- Colin On Tue, Mar 8, 2011 at 2:54 PM, Sam Pullara wrote: > Or just overload filter with a second argument that is the collection you > would like to add to. What is nice about the lazy collections is that you > don't need to generate intermediate collections at all and can much more > efficiently chain them. Perhaps make them all lazy and require a .to() at > the end if you want a Collection vs a Stream? > > > Collection fooAbles = things.filter(#Thing.isFoo).to(new > HashSet<>()); > > > Sam > > On Mar 8, 2011, at 11:42 AM, R?mi Forax wrote: > > > > > List things = ... > > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, > pretty > > > > > > Not that pretty because filter have to create a new collection and > > there is no way to do that apart hard coding a new ArrayList somewhere. > > > > It's better in my opinion to have a filterTo that takes a collection > > as argument. > > > > Collection fooAbles = things.filterTo(#Thing.isFoo, new > HashSet<>()); > > > > > > R?mi > > > > On 03/08/2011 06:23 PM, Brian Goetz wrote: > >> Since people are already discussing this based on an experimental > >> checkin, let me outline the big picture plan here. > >> > >> The general idea is to add functional-like operations to collections -- > >> filter, map, reduce, apply. > >> > >> I see three sensible modes, with explicit choices of which you get. > >> > >> 1. Serial / Eager. This is the straight > >> collections-with-functional-style mode, and some samples have already > >> been checked in as proof of concept. Operations on collections yield > >> new collections, and you can chain the calls. It values ease of use > >> over performance (no new concepts like laziness), but the performance > >> model is still highly predictable. You get things like > >> > >> Collection fooAbles = things.filter( #{ t -> t.isFoo() }); > >> > >> or, with method references: > >> > >> Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty > >> > >> You can also chain calls together, though you pay a (predictable) > >> performance cost of intermediate collections, which for small > >> collections is unlikely to matter: > >> > >> maxFooWeight = things.filter(#Thing.isFoo) > >> .map(#Thing.getWeight) > >> .max(); > >> > >> The benefit here is concision and clarity. The cost is some > >> performance, but maybe not so much that people freak out. If people > >> care, they move to the next model, which is: > >> > >> 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be > >> chosen later, Remi used "lazy" in his example.) To transfer between > >> "eager world" and "lazy world", you use conversion methods (toStream / > >> toCollection). A typical call chain probably looks like: > >> collection.toStream / op / op / op / {toCollection,reduce,apply} > >> > >> so the above example becomes > >> > >> maxFooWeight = things.asStream() > >> .filter(#Thing.isFoo) > >> .map(#Thing.getWeight) > >> .max(); > >> > >> The return type of Collection.filter is different from the return type > >> of Stream.filter, so the choice and performance costs are reflected in > >> the static type system. This avoids the cost of the intermediate > >> collections, but is still serial. If you care about that, you move up > >> to the next model, which is: > >> > >> 3. Parallel / Lazy. Here, the primary abstraction is something like > >> ParallelStream or ParallelIterable. Let's call it ParallelFoo to avoid > >> bikeshedding for the moment. Now, the code looks like: > >> > >> maxFooWeight = things.asParallelFoo() > >> .filter(#Thing.isFoo) > >> .map(#Thing.getWeight) > >> .max(); > >> > >> Again, the return type of ParallelFoo.filter is different from > >> Stream.filter or Collection.filter, so again the choice is reflected in > >> the static type system. But you don't have to rewrite your code. > >> > >> The beauty here is twofold: > >> > >> - The base model (serial/eager) is easy to understand and natural to > >> use as a way of expressing what the programmer wants to do, and > >> attractive enough to stand on its own -- just a little slow with big > >> collections. > >> - Switching between execution models is mostly a matter of adding an > >> explicit conversion or two in the call chain, as the models are similar > >> enough that the rest of the code should still work (and even mean the > >> same thing.) > >> > >> > >> On 3/8/2011 8:43 AM, R?mi Forax wrote: > >>> Le 08/03/2011 14:31, Jim Mayer a ?crit : > >>>> // I can tolerate this one > >>>> long product(List list) { > >>>> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> > sum * x}); > >>>> } > >>> I prefer this one: > >>> > >>> long product(List list) { > >>> return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, x > -> sum * x}); > >>> } > >>> > >>> lazy() means, don't do map directly, but wait and do map and reduce in > >>> one iteration. > >>> > >>> R?mi > >>> > >>> > > > > > > > From mcnepp02 at googlemail.com Tue Mar 8 12:56:13 2011 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Tue, 08 Mar 2011 21:56:13 +0100 Subject: Design for collections upgrades In-Reply-To: <4D7665FB.5070209@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: <4D7697ED.4040306@googlemail.com> I was thinking about the need for List comprehension methods to return a new Collection. As others have pointed out, there's always the time and space overhead involved, plus the question which Collection type to choose. And all that simply because Collection.size() exists and has to run with reasonable complexity! Maybe an appropriate return type for list comprehension methods would be java.lang.Iterable. Some advantages: - Allows creation of lightweight intermediate objects - Well-known interface - Immediately usable with foreach - Could be seamlessly integrated into existing Collections framework. If all the Standard Collection types get fitted with an additional constructor taking an Iterable, one could flexibly choose the target for 'filter' invocations on a per-case basis: Set fooAbles = new HashSet<>(things-filter( #{ t -> t.isFoo() }); List fooAbles = new ArrayList<>(things-filter( #{ t -> t.isFoo() }); And, of course, directly iterate over the result: for(Thing foo : things-filter( #{ t -> t.isFoo() })) { ... } A disadvantage would be the lack of chainable list comprehensions...unless, of course, we'd add the planned extension methods to java.lang.Iterable, which is not an altogether absurd idea, I guess. From brian.goetz at oracle.com Tue Mar 8 13:10:20 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 08 Mar 2011 16:10:20 -0500 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> Message-ID: <4D769B3C.8010601@oracle.com> > This would be my preference. Make everything that doesn't need to actually > iterate lazy by default and do copying at the end if necessary. We're reluctant to do that, because nothing else in Collections is lazy by default. This is one of the biggest gotchas of LinQ in .NET; the queries are lazy, but they sure look eager to the untrained eye, and this produces surprising results. We believe that a big difference like eager/lazy should be reflected in the type system, such as by returning an abstraction like Stream. Having some collections be lazy and some be eager is asking for trouble... Further, I think the choice of eager/lazy is a reasonable one to give the programmer. Programmers who do not need the features offered by laziness shouldn't need to learn how laziness works just to use the new collection operations. From neal at gafter.com Tue Mar 8 13:16:07 2011 From: neal at gafter.com (Neal Gafter) Date: Tue, 8 Mar 2011 13:16:07 -0800 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: <4D7665FB.5070209@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz wrote: > 1. Serial / Eager. This is the straight > collections-with-functional-style mode, and some samples have already > been checked in as proof of concept. Operations on collections yield > new collections, and you can chain the calls. It values ease of use > over performance (no new concepts like laziness), but the performance > model is still highly predictable. This form has problems: (1) there is no clear choice on the type of collection one should build as a result, and (2) it isn't clear this pays for itself in usefulness to client, and (3) it can be extremely inefficient in some contexts. Better to have the client use the Serial/Lazy APIs, and .toList(), .toSet(), or .toArray(), etc on the final result. In other words, I believe it makes sense for all of these operations to be "lazy", and only toList, toSet, toArray and their ilk would be eager. 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be > chosen later, Remi used "lazy" in his example.) The JDK already has two such streaming interfaces: Iterable and Collection. - Switching between execution models is mostly a matter of adding an > explicit conversion or two in the call chain, as the models are similar > enough that the rest of the code should still work (and even mean the > same thing.) > The semantics of the lazy and eager versions of these APIs are different enough, semantically, that I don't think they should even be named the same. (My preference is to do away with the eager bulk operations). Cheers, Neal From forax at univ-mlv.fr Tue Mar 8 13:16:33 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 08 Mar 2011 22:16:33 +0100 Subject: Design for collections upgrades In-Reply-To: <4D769B3C.8010601@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> <4D769B3C.8010601@oracle.com> Message-ID: <4D769CB1.4060702@univ-mlv.fr> On 03/08/2011 10:10 PM, Brian Goetz wrote: >> This would be my preference. Make everything that doesn't need to actually >> iterate lazy by default and do copying at the end if necessary. > We're reluctant to do that, because nothing else in Collections is lazy > by default. This is one of the biggest gotchas of LinQ in .NET; the > queries are lazy, but they sure look eager to the untrained eye, and > this produces surprising results. We believe that a big difference like > eager/lazy should be reflected in the type system, such as by returning > an abstraction like Stream. Having some collections be lazy and some be > eager is asking for trouble... Streams are lazy, Collection are eager. I think it's not incompatible with what Sam says. In things.filter(#Thing.isFoo).to(new HashSet<>), things.filter(#Thing.isFoo) will return a stream and to(new HashSet<>) will go back to the collection realm. > Further, I think the choice of eager/lazy is a reasonable one to give > the programmer. Programmers who do not need the features offered by > laziness shouldn't need to learn how laziness works just to use the new > collection operations. I don't see the need of having a eager filter(). R?mi From brian.goetz at oracle.com Tue Mar 8 13:24:22 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 08 Mar 2011 16:24:22 -0500 Subject: Design for collections upgrades In-Reply-To: <4D769CB1.4060702@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> <4D769B3C.8010601@oracle.com> <4D769CB1.4060702@univ-mlv.fr> Message-ID: <4D769E86.2090403@oracle.com> >> Further, I think the choice of eager/lazy is a reasonable one to give >> the programmer. Programmers who do not need the features offered by >> laziness shouldn't need to learn how laziness works just to use the new >> collection operations. > > I don't see the need of having a eager filter(). Java programs have lots of code that basically looks like this: ArrayList filtered = new ArrayList(); for (T t : otherList) if (predicate(t)) filtered.add(t); This can be replaced by the one liner: ArrayList filtered = otherList.filter(predicate); Not only is it shorter, it is clearer, less error-prone, and does not force the programmer to use side effects to do the computation. From forax at univ-mlv.fr Tue Mar 8 13:26:02 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 08 Mar 2011 22:26:02 +0100 Subject: Design for collections upgrades In-Reply-To: <4D769E86.2090403@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> <4D769B3C.8010601@oracle.com> <4D769CB1.4060702@univ-mlv.fr> <4D769E86.2090403@oracle.com> Message-ID: <4D769EEA.4090600@univ-mlv.fr> On 03/08/2011 10:24 PM, Brian Goetz wrote: >>> Further, I think the choice of eager/lazy is a reasonable one to give >>> the programmer. Programmers who do not need the features offered by >>> laziness shouldn't need to learn how laziness works just to use the new >>> collection operations. >> >> I don't see the need of having a eager filter(). > > Java programs have lots of code that basically looks like this: > > ArrayList filtered = new ArrayList(); > for (T t : otherList) > if (predicate(t)) > filtered.add(t); > > This can be replaced by the one liner: > > ArrayList filtered = otherList.filter(predicate); > > Not only is it shorter, it is clearer, less error-prone, and does not > force the programmer to use side effects to do the computation. > Is this one will also works ? LinkedList filtered = otherList.filter(predicate); R?mi From sam at sampullara.com Tue Mar 8 13:32:13 2011 From: sam at sampullara.com (Sam Pullara) Date: Tue, 8 Mar 2011 13:32:13 -0800 Subject: Design for collections upgrades In-Reply-To: <4D769E86.2090403@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> <4D769B3C.8010601@oracle.com> <4D769CB1.4060702@univ-mlv.fr> <4D769E86.2090403@oracle.com> Message-ID: <0C0C22A6-BE99-49B0-AC08-49C3BB42F381@sampullara.com> I think this is exactly the issue we are talking about. It is unclear what the performance of the list after it is returned to me. I'd be much happier a one liner that looked like: List filtered = new ArrayList(otherList.filter(predicate)); or List filtered = otherList.filter(predicate).to(new ArrayList<>()); Generally you shouldn't be even looking at the result. What would be much better is that you just perform the next action: otherList.filter(predicate).each(operation); or for (T t : otherList.filter(predicate)) { operation } Sam On Mar 8, 2011, at 1:24 PM, Brian Goetz wrote: >>> Further, I think the choice of eager/lazy is a reasonable one to give >>> the programmer. Programmers who do not need the features offered by >>> laziness shouldn't need to learn how laziness works just to use the new >>> collection operations. >> >> I don't see the need of having a eager filter(). > > Java programs have lots of code that basically looks like this: > > ArrayList filtered = new ArrayList(); > for (T t : otherList) > if (predicate(t)) > filtered.add(t); > > This can be replaced by the one liner: > > ArrayList filtered = otherList.filter(predicate); > > Not only is it shorter, it is clearer, less error-prone, and does not > force the programmer to use side effects to do the computation. > > From forax at univ-mlv.fr Tue Mar 8 13:34:19 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 08 Mar 2011 22:34:19 +0100 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: <4D76A0DB.2000206@univ-mlv.fr> On 03/08/2011 10:16 PM, Neal Gafter wrote: > On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz wrote: > >> 1. Serial / Eager. This is the straight >> collections-with-functional-style mode, and some samples have already >> been checked in as proof of concept. Operations on collections yield >> new collections, and you can chain the calls. It values ease of use >> over performance (no new concepts like laziness), but the performance >> model is still highly predictable. > > This form has problems: (1) there is no clear choice on the type of > collection one should build as a result, and (2) it isn't clear this pays > for itself in usefulness to client, and (3) it can be extremely inefficient > in some contexts. Better to have the client use the Serial/Lazy APIs, and > .toList(), .toSet(), or .toArray(), etc on the final result. In other > words, I believe it makes sense for all of these operations to be "lazy", > and only toList, toSet, toArray and their ilk would be eager. Not all operations are lazy. Reduce is not lazy. > 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be >> chosen later, Remi used "lazy" in his example.) > > The JDK already has two such streaming interfaces: Iterable and > Collection. Not sure we can reuse them, I have to think about that. > - Switching between execution models is mostly a matter of adding an >> explicit conversion or two in the call chain, as the models are similar >> enough that the rest of the code should still work (and even mean the >> same thing.) >> > The semantics of the lazy and eager versions of these APIs are different > enough, semantically, that I don't think they should even be named the > same. (My preference is to do away with the eager bulk operations). > > Cheers, > Neal > R?mi From lk at teamten.com Tue Mar 8 13:37:37 2011 From: lk at teamten.com (Lawrence Kesteloot) Date: Tue, 8 Mar 2011 13:37:37 -0800 Subject: Design for collections upgrades In-Reply-To: <4D769E86.2090403@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> <4D769B3C.8010601@oracle.com> <4D769CB1.4060702@univ-mlv.fr> <4D769E86.2090403@oracle.com> Message-ID: On Tue, Mar 8, 2011 at 1:24 PM, Brian Goetz wrote: > This can be replaced by the one liner: > > ArrayList filtered = otherList.filter(predicate); This isn't a very strong argument, since the following is more clear and flexible: ArrayList filtered = new ArrayList(otherList.filter(predicate)); (Assuming that filter() returns a Stream and that an ArrayList constructor takes one. This also answers Remi's question about LinkedList.) A better argument against making filter() return a stream is that it's unexpected. The verb "filter" means "filter", not "create a stream that when later evaluated will filter." You can imagine users putting logging statements in their predicates, calling: otherList.filter(predicate) and not seeing anything logged. Or programmers repeatedly evaluating the contents of the stream, not realizing that they're calling the predicate every time. I don't feel strongly that we must have an eager API, but I do feel like we can't have a streaming API that looks like an eager one. Lawrence From sam at sampullara.com Tue Mar 8 13:41:02 2011 From: sam at sampullara.com (Sam Pullara) Date: Tue, 8 Mar 2011 13:41:02 -0800 Subject: Design for collections upgrades In-Reply-To: <4D76A0DB.2000206@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76A0DB.2000206@univ-mlv.fr> Message-ID: I On Mar 8, 2011, at 1:34 PM, R?mi Forax wrote: > On 03/08/2011 10:16 PM, Neal Gafter wrote: >> On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz wrote: >> 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be >>> chosen later, Remi used "lazy" in his example.) >> >> The JDK already has two such streaming interfaces: Iterable and >> Collection. > > Not sure we can reuse them, I have to think about that. Iterable is what I use with Google Collections + anonymous classes and it works reasonably well. Extension methods should help fix the warts on iterator() as well. Sam From brian.goetz at oracle.com Tue Mar 8 13:44:42 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 08 Mar 2011 16:44:42 -0500 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> <4D769B3C.8010601@oracle.com> <4D769CB1.4060702@univ-mlv.fr> <4D769E86.2090403@oracle.com> Message-ID: <4D76A34A.9000803@oracle.com> > I don't feel strongly that we must have an eager > API, but I do feel like we can't have a streaming API that looks like > an eager one. I would agree with this position. There are pluses and minuses for the eager version, but we can't make the default API either lazy or parallel - you have to ask for that, and it should be reflected in the (static) type system. From howard.lovatt at gmail.com Tue Mar 8 14:27:32 2011 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Wed, 9 Mar 2011 09:27:32 +1100 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: +1 for Neal's suggestions, I have also found: to( T[] result ) and to( Collection result ) to be useful, i.e. much like toArray( T[] result ) in List. -- Howard. PS I think someone else has previously suggested the to() methods with lazy evaluation as the best interface (unfortunately I can't remember who that was and therefore can't give credit where credit is due). On 9 March 2011 08:16, Neal Gafter wrote: > On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz wrote: > >> 1. ?Serial / Eager. ?This is the straight >> collections-with-functional-style mode, and some samples have already >> been checked in as proof of concept. ?Operations on collections yield >> new collections, and you can chain the calls. ?It values ease of use >> over performance (no new concepts like laziness), but the performance >> model is still highly predictable. > > > This form has problems: (1) there is no clear choice on the type of > collection one should build as a result, and (2) it isn't clear this pays > for itself in usefulness to client, and (3) it can be extremely inefficient > in some contexts. ?Better to have the client use the Serial/Lazy APIs, and > .toList(), .toSet(), or .toArray(), etc on the final result. ?In other > words, I believe it makes sense for all of these operations to be "lazy", > and only toList, toSet, toArray and their ilk would be eager. > > 2. ?Serial / Lazy. ?Here, the primary abstraction is Stream (name to be >> chosen later, Remi used "lazy" in his example.) > > > The JDK already has two such streaming interfaces: Iterable and > Collection. > > - Switching between execution models is mostly a matter of adding an >> explicit conversion or two in the call chain, as the models are similar >> enough that the rest of the code should still work (and even mean the >> same thing.) >> > > The semantics of the lazy and eager versions of these APIs are different > enough, semantically, that I don't think they should even be named the > same. ?(My preference is to do away with the eager bulk operations). > > Cheers, > Neal > > -- ? -- Howard. From cgdecker at gmail.com Tue Mar 8 14:55:02 2011 From: cgdecker at gmail.com (Colin Decker) Date: Tue, 8 Mar 2011 17:55:02 -0500 Subject: Design for collections upgrades In-Reply-To: <4D76A34A.9000803@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> <4D769B3C.8010601@oracle.com> <4D769CB1.4060702@univ-mlv.fr> <4D769E86.2090403@oracle.com> <4D76A34A.9000803@oracle.com> Message-ID: If there isn't an eager API, the streaming API won't look eager. I can appreciate not wanting to confuse people who expect filter() to be eager because they're used to copying filtered values into a new collection, but that's often not the best thing to do, as has already been pointed out. Users have been doing that for everything because there hasn't been any other way provided. I think that filter, map, etc. should be extension methods on Iterable. Barring that, the Stream interface or whatever it's called should be Iterable. Users can't confuse the results of map and filter with eager Collection copies if those results aren't of the right type. As I see it, all you gain from an eager API is the ability to create a new Collection (of a type you have no control over) without calling a copy method, plus the ability to shoot yourself in the foot over and over with unnecessary chaining of eager calls. -- Colin On Tue, Mar 8, 2011 at 4:44 PM, Brian Goetz wrote: > > I don't feel strongly that we must have an eager > > API, but I do feel like we can't have a streaming API that looks like > > an eager one. > > I would agree with this position. There are pluses and minuses for the > eager version, but we can't make the default API either lazy or parallel > - you have to ask for that, and it should be reflected in the (static) > type system. > > From int19h at gmail.com Tue Mar 8 15:05:22 2011 From: int19h at gmail.com (Pavel Minaev) Date: Tue, 8 Mar 2011 15:05:22 -0800 Subject: Design for collections upgrades In-Reply-To: <4D76A34A.9000803@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> <4D769B3C.8010601@oracle.com> <4D769CB1.4060702@univ-mlv.fr> <4D769E86.2090403@oracle.com> <4D76A34A.9000803@oracle.com> Message-ID: On Tue, Mar 8, 2011 at 1:44 PM, Brian Goetz wrote: > I would agree with this position. There are pluses and minuses for the > eager version, but we can't make the default API either lazy or parallel > - you have to ask for that, and it should be reflected in the (static) > type system. > > How would the (default) eager API look when applied to an Iterable receiver? i.e. how would it decide the resulting collection type then? As a side note, if you do decide to have a separate interface solely to indicate laziness, please do not call it Stream. It's certainly tempting, but it invites confusion with I/O streams. As noted earlier by Neal, the correct abstraction for this already exists and is Iterable. If the only distinction of this type is that it is (potentially) lazily evaluated, then call it LazyIterable or DeferredIterable. From howard.lovatt at gmail.com Tue Mar 8 15:20:20 2011 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Wed, 9 Mar 2011 10:20:20 +1100 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> <4D769B3C.8010601@oracle.com> <4D769CB1.4060702@univ-mlv.fr> <4D769E86.2090403@oracle.com> <4D76A34A.9000803@oracle.com> Message-ID: I agree with all Colin has said below re. using Iterable as the stream and not having an eager version at all and would suggest: convert, filter, and fold as the method names to be consistent with the MethodHandle API where you can convert, filter, and fold argument lists. It is good to be consistent with other APIs and also map is used for a HashMap already. -- Howard. On 9 March 2011 09:55, Colin Decker wrote: > If there isn't an eager API, the streaming API won't look eager. I can > appreciate not wanting to confuse people who expect filter() to be eager > because they're used to copying filtered values into a new collection, > but that's often not the best thing to do, as has already been pointed out. > Users have been doing that for everything because there hasn't been any > other way provided. > > I think that filter, map, etc. should be extension methods on Iterable. > Barring that, the Stream interface or whatever it's called should be > Iterable. Users can't confuse the results of map and filter with eager > Collection copies if those results aren't of the right type. > > As I see it, all you gain from an eager API is the ability to create a new > Collection (of a type you have no control over) without calling a copy > method, plus the ability to shoot yourself in the foot over and over with > unnecessary chaining of eager calls. > > -- > Colin > > > On Tue, Mar 8, 2011 at 4:44 PM, Brian Goetz wrote: > >> ?> I don't feel strongly that we must have an eager >> > API, but I do feel like we can't have a streaming API that looks like >> > an eager one. >> >> I would agree with this position. ?There are pluses and minuses for the >> eager version, but we can't make the default API either lazy or parallel >> - you have to ask for that, and it should be reflected in the (static) >> type system. >> >> > > -- ? -- Howard. From ola.bini at gmail.com Tue Mar 8 15:23:53 2011 From: ola.bini at gmail.com (Ola Bini) Date: Tue, 08 Mar 2011 17:23:53 -0600 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> <4D769B3C.8010601@oracle.com> <4D769CB1.4060702@univ-mlv.fr> <4D769E86.2090403@oracle.com> Message-ID: <4D76BA89.1040300@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > A better argument against making filter() return a stream is that it's > unexpected. The verb "filter" means "filter", not "create a stream > that when later evaluated will filter." You can imagine users putting I personally am a fan of this argument. I ended up using the past tense for lazy sequences in Ioke for this specific reason. It becomes immediately obvious if you're in strict or lazy-land based on the tense of the method names. To Brian's argument, the type system will tell you too, but that's not always apparent from reading a specific line of code. Cheers - -- Ola Bini (http://olabini.com) Ioke - JRuby - ThoughtWorks "Yields falsehood when quined" yields falsehood when quined. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNdrqIAAoJEClcdGmEr38MVewP/j39GdhfgPjYoPrTxOHJfnMt bNd6eEN+mTudRm2iy7saUriwTwC6huQY0jZdL384wS+0xB3FzqQ27vymaubIsjCl eAa8Ld3mTvOtuvN8PEd2DAJfU2TfNLI9j/dhJnkMoDGUUDohi02EoVHW5SPFVYYm OWJiKwEPs0fOd+T7A5hk065a2sv8x63J5D7T26rzFnDzVqPak9QfxSkgjUh61go3 o1j99BE1YpNIuvFQJ8vI5VrUeCXMor900H+1tUMojEmKrGrtUGsdfqAZM9a6awq8 Iy/CpLX3cyplFkb0fDlie5XhWkvknZJ7E2pcDmQFYXaSQ9v4U25c2CMu7SpXCMNw JNGxtbVvWJnrAxzI4P2Ss0JMsbAcDYUDG7sI19LVt9gEH+uRQSwkh2pcSgMNwXBt DXWx6RVIRE9zVL2H0e7WHArdj1oc1NG57/FLh38wVMkV0iMs5ycvrjK4Kph/clPQ zlIJnbjsyuyn5uQycuLsGIBo0TTaPbw29r8QTPKaMQCsxF2PZQnWh7NqgBRTAjQi RQzbBMcsfpPJgoBRydyBBaZtUW+GmVCHGJ//TB3J387gD8OQp8AlDL+M6JFJ8y/c lUpbAZxoHIz79cut68H2MqE3I2qHsNmwVt1ARmy8L/Yxxhm/eWXVCaF8TxbdJk15 pMNgRc2teUUoYb4/WhJJ =f6kE -----END PGP SIGNATURE----- From sam at sampullara.com Tue Mar 8 15:25:32 2011 From: sam at sampullara.com (Sam Pullara) Date: Tue, 8 Mar 2011 15:25:32 -0800 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> <4D769B3C.8010601@oracle.com> <4D769CB1.4060702@univ-mlv.fr> <4D769E86.2090403@oracle.com> <4D76A34A.9000803@oracle.com> Message-ID: Isn't the eager version really copy(Predicate) rather than filter() that defaults to the concrete type of its source type? Sam On Mar 8, 2011, at 2:55 PM, Colin Decker wrote: > If there isn't an eager API, the streaming API won't look eager. I can > appreciate not wanting to confuse people who expect filter() to be eager > because they're used to copying filtered values into a new collection, > but that's often not the best thing to do, as has already been pointed out. > Users have been doing that for everything because there hasn't been any > other way provided. > > I think that filter, map, etc. should be extension methods on Iterable. > Barring that, the Stream interface or whatever it's called should be > Iterable. Users can't confuse the results of map and filter with eager > Collection copies if those results aren't of the right type. > > As I see it, all you gain from an eager API is the ability to create a new > Collection (of a type you have no control over) without calling a copy > method, plus the ability to shoot yourself in the foot over and over with > unnecessary chaining of eager calls. > > -- > Colin > > > On Tue, Mar 8, 2011 at 4:44 PM, Brian Goetz wrote: > >>> I don't feel strongly that we must have an eager >>> API, but I do feel like we can't have a streaming API that looks like >>> an eager one. >> >> I would agree with this position. There are pluses and minuses for the >> eager version, but we can't make the default API either lazy or parallel >> - you have to ask for that, and it should be reflected in the (static) >> type system. >> >> > From scolebourne at joda.org Tue Mar 8 15:49:37 2011 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 8 Mar 2011 23:49:37 +0000 Subject: Design for collections upgrades In-Reply-To: <4D76BA89.1040300@gmail.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> <4D769B3C.8010601@oracle.com> <4D769CB1.4060702@univ-mlv.fr> <4D769E86.2090403@oracle.com> <4D76BA89.1040300@gmail.com> Message-ID: On 8 March 2011 23:23, Ola Bini wrote: >> A better argument against making filter() return a stream is that it's >> unexpected. The verb "filter" means "filter", not "create a stream >> that when later evaluated will filter." You can imagine users putting > I personally am a fan of this argument. I ended up using the past tense > for lazy sequences in Ioke for this specific reason. It becomes > immediately obvious if you're in strict or lazy-land based on the tense > of the method names. To Brian's argument, the type system will tell you > too, but that's not always apparent from reading a specific line of code. Sounds like a coding style I've used: list.filter(predicate) // alters list itself list.filtered(predicate) // returns a new list This chimes with the use of past tense in JSR-310, Joda-Time and similar. Stephen From int19h at gmail.com Tue Mar 8 16:59:33 2011 From: int19h at gmail.com (Pavel Minaev) Date: Tue, 8 Mar 2011 16:59:33 -0800 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> <4D769B3C.8010601@oracle.com> <4D769CB1.4060702@univ-mlv.fr> <4D769E86.2090403@oracle.com> <4D76BA89.1040300@gmail.com> Message-ID: On Tue, Mar 8, 2011 at 3:49 PM, Stephen Colebourne wrote: > On 8 March 2011 23:23, Ola Bini wrote: > >> A better argument against making filter() return a stream is that it's > >> unexpected. The verb "filter" means "filter", not "create a stream > >> that when later evaluated will filter." You can imagine users putting > > I personally am a fan of this argument. I ended up using the past tense > > for lazy sequences in Ioke for this specific reason. It becomes > > immediately obvious if you're in strict or lazy-land based on the tense > > of the method names. To Brian's argument, the type system will tell you > > too, but that's not always apparent from reading a specific line of code. > > Sounds like a coding style I've used: > list.filter(predicate) // alters list itself > list.filtered(predicate) // returns a new list > It is a common pattern, but in this case the first version isn't in-place filtering - it's also "return a new X". The difference between the two is when the filtering does happen - before the return, or after. I don't think that past vs present tense gives a good clue there, either. In fact, using past tense for lazy ops also sounds like a misnomer because it implies that the operation has already completed by the time method returns, which is not the case. I generally prefer the standard convention of map/filter/... compared to .NET select/where/..., but it now strikes me that the latter naming is indeed less ambiguous for the lazy case - it does not imply in-place modification, nor does it carry a strong connotation of preserving the source collection type. Then again, what's wrong with the original Brian's code where you had to use asLazy() on the collection to "enter the lazy land", where all operation names are the same, but all effects are deferred inasmuch as possible? It seems that intent indicated there clearly enough; are distinct names for operations actually needed in that case? From sam at sampullara.com Tue Mar 8 17:05:05 2011 From: sam at sampullara.com (Sam Pullara) Date: Tue, 8 Mar 2011 17:05:05 -0800 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> <4D769B3C.8010601@oracle.com> <4D769CB1.4060702@univ-mlv.fr> <4D769E86.2090403@oracle.com> <4D76BA89.1040300@gmail.com> Message-ID: <01E0B426-B06B-4960-8482-2A2463D2FE33@sampullara.com> The problem was that there wasn't any obvious way to know what the concrete type of the resulting collection would be in the eager case. Presumably people care what data structure is being used under the covers. Sam On Mar 8, 2011, at 4:59 PM, Pavel Minaev wrote: > On Tue, Mar 8, 2011 at 3:49 PM, Stephen Colebourne wrote: > >> On 8 March 2011 23:23, Ola Bini wrote: >>>> A better argument against making filter() return a stream is that it's >>>> unexpected. The verb "filter" means "filter", not "create a stream >>>> that when later evaluated will filter." You can imagine users putting >>> I personally am a fan of this argument. I ended up using the past tense >>> for lazy sequences in Ioke for this specific reason. It becomes >>> immediately obvious if you're in strict or lazy-land based on the tense >>> of the method names. To Brian's argument, the type system will tell you >>> too, but that's not always apparent from reading a specific line of code. >> >> Sounds like a coding style I've used: >> list.filter(predicate) // alters list itself >> list.filtered(predicate) // returns a new list >> > > It is a common pattern, but in this case the first version isn't in-place > filtering - it's also "return a new X". The difference between the two is > when the filtering does happen - before the return, or after. > > I don't think that past vs present tense gives a good clue there, either. In > fact, using past tense for lazy ops also sounds like a misnomer because it > implies that the operation has already completed by the time method returns, > which is not the case. > > I generally prefer the standard convention of map/filter/... compared to > .NET select/where/..., but it now strikes me that the latter naming is > indeed less ambiguous for the lazy case - it does not imply in-place > modification, nor does it carry a strong connotation of preserving the > source collection type. > > Then again, what's wrong with the original Brian's code where you had to use > asLazy() on the collection to "enter the lazy land", where all operation > names are the same, but all effects are deferred inasmuch as possible? It > seems that intent indicated there clearly enough; are distinct names for > operations actually needed in that case? > From jim at pentastich.org Tue Mar 8 17:46:34 2011 From: jim at pentastich.org (Jim Mayer) Date: Tue, 8 Mar 2011 20:46:34 -0500 Subject: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] In-Reply-To: References: Message-ID: Arghh... that should have read "I would also like to see the result type be independent of the collection's element type". My only excuse is that English is my first language. -- Jim On Tue, Mar 8, 2011 at 8:31 AM, Jim Mayer wrote: > I would also like to see the result type to be the same as the collection's > element type. > > While I think it's true that one can combine map and a uniform fold > function to get a similar result (especially if one introduces intermediate > objects in the map (e.g., 'Pair')), I think it also results in more verbose, > less transparent, code. Compare the following (I'm not up on the syntax of > the proposed collections changes, so please bear with me): > > // I like this one > long product(List list) { > return list.reduce(0L, #{ sum, x -> sum * x }); > } > > or > > // I can tolerate this one > long product(List list) { > return Collections.reduce(list, 0L, #{ sum, x -> sum * x }); > } > > to > > // I can tolerate this one > long product(List list) { > return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> sum * x}); > } > > or > > // This one makes me gag > long product(List list) { > return Collections.reduce(Collections.map(list, #{x -> (long) x}), > 0L, #{sum, x -> sum * x}); > } > > More fundamentally, operators like 'reduce', 'foldLeft', whatever, seem > mathematical in nature. Most mathematical notations talk about 'integers' > or 'numbers' (or 'groups', for that matter). They don't usually talk about > '32 bit integers' or '64 bit integers'. Java numbers, on the other hand, > are fixed size and we can't ignore that. To me, the first example above > clearly expresses the mathematical concept of 'product' while respecting > Java's primitive types. In the second, though, the type conversion > implemented by the 'map' seems extraneous to the 'product' concept. > > While I don't share Lawrence Kesteloot's belief that "I can genuinely see > why computer science theorists love fold-left, but it doesn't belong in > any code that will later be read > by a human", I do object to deeply nested compositions of map/reduce like > operations. > > -- Jim > > The second > > On Mon, Mar 7, 2011 at 9:30 PM, Neal Gafter wrote: > >> On Mon, Mar 7, 2011 at 3:57 PM, Mike Duigou >> wrote: >> >> > > From: Neal Gafter >> > > Date: February 23, 2011 07:49:49 PST >> > > >> > > The "reduce" (left fold) method should not require the result type to >> be >> > the >> > > same as the collection's element type. >> > >> > That was my reaction as well but Brian convinced me that having a >> different >> > result and initial type was just a conflation of map with reduce. After >> > thinking about it for a while I've been unable to come up with any cases >> > that couldn't be satisfied by a map step (which may merely do type >> > conversion) before the reduce step. Is there another reason to have >> reduce >> > return a different type than the element? >> > >> >> I should start by pointing out that the map/reduce formality popularized >> by >> Google has little to do with this API, as Google's "reduce" operation >> produces a collection of results. To avoid confusion I will call Lambda's >> operation "fold". >> >> To answer your question: >> >> First, it is strictly more expressive, as the fold function with separate >> input and result types has more information to work with than either the >> mapping function or the fold function in separate map/fold steps (though >> you >> can get the same effect by introducing extra mapping steps to preserve the >> needed data in intermediate types). Second, the "initial" value in the >> fold >> operation doesn't provide much value if the fold operation is >> homogeneously >> typed. >> >> Finally, there is a great deal of experience with these kinds of bulk data >> APIs in the functional programming community, who after long experience >> have >> come to prefer the version in which the source and destination types may >> differ. It would be a shame to ignore their experience and repeat >> mistakes >> of the distant past. See also > universality and expressiveness of fold" from the Journal of Functional >> Programming (9 (4)) > and > foldLeft operation< >> http://functionaljava.googlecode.com/svn/artifacts/3.0/javadoc/fj/data/List.html#foldLeft%28fj.F2,%20B%29 >> >> >> or, for some simple examples, > foldLeft Examples"< >> http://oldfashionedsoftware.com/2009/07/30/lots-and-lots-of-foldleft-examples/ >> > >> >. >> >> Being composed of experts, I expect that the Project Lambda JSR expert >> group >> has members who are well versed in these techniques. >> >> Cheers, >> Neal >> >> > From collin.fagan at gmail.com Tue Mar 8 18:20:39 2011 From: collin.fagan at gmail.com (Collin Fagan) Date: Tue, 8 Mar 2011 20:20:39 -0600 Subject: Design for collections upgrades In-Reply-To: <01E0B426-B06B-4960-8482-2A2463D2FE33@sampullara.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <85A0510F-CE48-4587-9DCE-E41904F5C6C3@sampullara.com> <4D769B3C.8010601@oracle.com> <4D769CB1.4060702@univ-mlv.fr> <4D769E86.2090403@oracle.com> <4D76BA89.1040300@gmail.com> <01E0B426-B06B-4960-8482-2A2463D2FE33@sampullara.com> Message-ID: If we had constructor references, we could just pass one for the collection we want to use, even way early in the process. Each step would then have the option of creating any number of correctly typed collections necessary to get it's job done. I know constructor references have been requested but I'm not sure if it's on the list of features under consideration by the expert group. Co*ll*in (with 2 l's, not to be confused with Mr. Decker) On Tue, Mar 8, 2011 at 7:05 PM, Sam Pullara wrote: > The problem was that there wasn't any obvious way to know what the concrete > type of the resulting collection would be in the eager case. Presumably > people care what data structure is being used under the covers. > > Sam > > On Mar 8, 2011, at 4:59 PM, Pavel Minaev wrote: > > > On Tue, Mar 8, 2011 at 3:49 PM, Stephen Colebourne >wrote: > > > >> On 8 March 2011 23:23, Ola Bini wrote: > >>>> A better argument against making filter() return a stream is that it's > >>>> unexpected. The verb "filter" means "filter", not "create a stream > >>>> that when later evaluated will filter." You can imagine users putting > >>> I personally am a fan of this argument. I ended up using the past tense > >>> for lazy sequences in Ioke for this specific reason. It becomes > >>> immediately obvious if you're in strict or lazy-land based on the tense > >>> of the method names. To Brian's argument, the type system will tell you > >>> too, but that's not always apparent from reading a specific line of > code. > >> > >> Sounds like a coding style I've used: > >> list.filter(predicate) // alters list itself > >> list.filtered(predicate) // returns a new list > >> > > > > It is a common pattern, but in this case the first version isn't in-place > > filtering - it's also "return a new X". The difference between the two is > > when the filtering does happen - before the return, or after. > > > > I don't think that past vs present tense gives a good clue there, either. > In > > fact, using past tense for lazy ops also sounds like a misnomer because > it > > implies that the operation has already completed by the time method > returns, > > which is not the case. > > > > I generally prefer the standard convention of map/filter/... compared to > > .NET select/where/..., but it now strikes me that the latter naming is > > indeed less ambiguous for the lazy case - it does not imply in-place > > modification, nor does it carry a strong connotation of preserving the > > source collection type. > > > > Then again, what's wrong with the original Brian's code where you had to > use > > asLazy() on the collection to "enter the lazy land", where all operation > > names are the same, but all effects are deferred inasmuch as possible? It > > seems that intent indicated there clearly enough; are distinct names for > > operations actually needed in that case? > > > > > From jim at pentastich.org Tue Mar 8 19:22:19 2011 From: jim at pentastich.org (Jim Mayer) Date: Tue, 8 Mar 2011 22:22:19 -0500 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: I am a huge fan of lazy evaluation. I think I like the "to( Collection result )" syntax that Howard mentions, but I'm concerned about the fact that, in general, the size of the result can't be known in advance. Methods like "toList" might be able to chose implementations that are especially efficient for interfacing with the stream implementation. Some questions: 1. Would the stream types implement Iterable? If the did, then one could write "for (Fu x : something.asStream().map(#{...})) {...}", which would be a nice bridge to the existing language and which would avoid instantiating an unnecessary intermediate collection. 2. Are you anticipating an explicit API for creating the stream types outside of the collections classes? 3. With lazy evaluation, one can cleanly represent infinite series. Would we we enable this? 4. Would "Iterator" get an "asStream" method? I suppose that would cover (2) and (3). 5. What about operations on streams (e.g., concatenation, interleaving, selection (i.e., use values in one stream to select values from another)? 6. Is there anything clever that can be done when generating arrays, ArrayLists, etc. from a stream? When filters are used the size of the result won't be known until the entire stream is processed, but in some cases one might be able to know the final size (or, in other cases, an upper bound). 7. Have you considered adding constructors to the collection classes that take streams (e.g., new ArrayList(Stream))? I'd better stop :-) This reminds me of Richard Water's SERIES package for common list ( http://series.sourceforge.net/). It's been a while, but I really enjoyed using it. -- Jim On Tue, Mar 8, 2011 at 5:27 PM, Howard Lovatt wrote: > +1 for Neal's suggestions, I have also found: > > to( T[] result ) and to( Collection result ) to be useful, i.e. > much like toArray( T[] result ) in List. > > -- Howard. > > PS I think someone else has previously suggested the to() methods with > lazy evaluation as the best interface (unfortunately I can't remember > who that was and therefore can't give credit where credit is due). > > On 9 March 2011 08:16, Neal Gafter wrote: > > On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz > wrote: > > > >> 1. Serial / Eager. This is the straight > >> collections-with-functional-style mode, and some samples have already > >> been checked in as proof of concept. Operations on collections yield > >> new collections, and you can chain the calls. It values ease of use > >> over performance (no new concepts like laziness), but the performance > >> model is still highly predictable. > > > > > > This form has problems: (1) there is no clear choice on the type of > > collection one should build as a result, and (2) it isn't clear this pays > > for itself in usefulness to client, and (3) it can be extremely > inefficient > > in some contexts. Better to have the client use the Serial/Lazy APIs, > and > > .toList(), .toSet(), or .toArray(), etc on the final result. In other > > words, I believe it makes sense for all of these operations to be "lazy", > > and only toList, toSet, toArray and their ilk would be eager. > > > > 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be > >> chosen later, Remi used "lazy" in his example.) > > > > > > The JDK already has two such streaming interfaces: Iterable and > > Collection. > > > > - Switching between execution models is mostly a matter of adding an > >> explicit conversion or two in the call chain, as the models are similar > >> enough that the rest of the code should still work (and even mean the > >> same thing.) > >> > > > > The semantics of the lazy and eager versions of these APIs are different > > enough, semantically, that I don't think they should even be named the > > same. (My preference is to do away with the eager bulk operations). > > > > Cheers, > > Neal > > > > > > > > -- > -- Howard. > > From tronicek at fit.cvut.cz Thu Mar 10 02:46:06 2011 From: tronicek at fit.cvut.cz (=?utf-8?B?IlpkZW7Em2sgVHJvbsOtxI1layI=?=) Date: Thu, 10 Mar 2011 11:46:06 +0100 Subject: Design for collections upgrades In-Reply-To: <4D76869C.7010203@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> Message-ID: To me it seems logical that filter() returns the same collection as was the original collection. For Set you do not have any other choice either: set.filter(predicate) cannot switch from HashSet to TreeSet or back. Z. -- Zdenek Tronicek FIT CTU in Prague R?mi Forax napsal(a): > > List things = ... > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, > pretty > > > Not that pretty because filter have to create a new collection and > there is no way to do that apart hard coding a new ArrayList somewhere. > > It's better in my opinion to have a filterTo that takes a collection > as argument. > > Collection fooAbles = things.filterTo(#Thing.isFoo, new > HashSet<>()); > > > R?mi > > On 03/08/2011 06:23 PM, Brian Goetz wrote: >> Since people are already discussing this based on an experimental >> checkin, let me outline the big picture plan here. >> >> The general idea is to add functional-like operations to collections -- >> filter, map, reduce, apply. >> >> I see three sensible modes, with explicit choices of which you get. >> >> 1. Serial / Eager. This is the straight >> collections-with-functional-style mode, and some samples have already >> been checked in as proof of concept. Operations on collections yield >> new collections, and you can chain the calls. It values ease of use >> over performance (no new concepts like laziness), but the performance >> model is still highly predictable. You get things like >> >> Collection fooAbles = things.filter( #{ t -> t.isFoo() }); >> >> or, with method references: >> >> Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty >> >> You can also chain calls together, though you pay a (predictable) >> performance cost of intermediate collections, which for small >> collections is unlikely to matter: >> >> maxFooWeight = things.filter(#Thing.isFoo) >> .map(#Thing.getWeight) >> .max(); >> >> The benefit here is concision and clarity. The cost is some >> performance, but maybe not so much that people freak out. If people >> care, they move to the next model, which is: >> >> 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be >> chosen later, Remi used "lazy" in his example.) To transfer between >> "eager world" and "lazy world", you use conversion methods (toStream / >> toCollection). A typical call chain probably looks like: >> collection.toStream / op / op / op / {toCollection,reduce,apply} >> >> so the above example becomes >> >> maxFooWeight = things.asStream() >> .filter(#Thing.isFoo) >> .map(#Thing.getWeight) >> .max(); >> >> The return type of Collection.filter is different from the return type >> of Stream.filter, so the choice and performance costs are reflected in >> the static type system. This avoids the cost of the intermediate >> collections, but is still serial. If you care about that, you move up >> to the next model, which is: >> >> 3. Parallel / Lazy. Here, the primary abstraction is something like >> ParallelStream or ParallelIterable. Let's call it ParallelFoo to avoid >> bikeshedding for the moment. Now, the code looks like: >> >> maxFooWeight = things.asParallelFoo() >> .filter(#Thing.isFoo) >> .map(#Thing.getWeight) >> .max(); >> >> Again, the return type of ParallelFoo.filter is different from >> Stream.filter or Collection.filter, so again the choice is reflected in >> the static type system. But you don't have to rewrite your code. >> >> The beauty here is twofold: >> >> - The base model (serial/eager) is easy to understand and natural to >> use as a way of expressing what the programmer wants to do, and >> attractive enough to stand on its own -- just a little slow with big >> collections. >> - Switching between execution models is mostly a matter of adding an >> explicit conversion or two in the call chain, as the models are similar >> enough that the rest of the code should still work (and even mean the >> same thing.) >> >> >> On 3/8/2011 8:43 AM, R?mi Forax wrote: >>> Le 08/03/2011 14:31, Jim Mayer a ?crit : >>>> // I can tolerate this one >>>> long product(List list) { >>>> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> >>>> sum * x}); >>>> } >>> I prefer this one: >>> >>> long product(List list) { >>> return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, >>> x -> sum * x}); >>> } >>> >>> lazy() means, don't do map directly, but wait and do map and reduce in >>> one iteration. >>> >>> R?mi >>> >>> > > > From forax at univ-mlv.fr Thu Mar 10 03:04:41 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Thu, 10 Mar 2011 12:04:41 +0100 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> Message-ID: <4D78B049.7000907@univ-mlv.fr> Le 10/03/2011 11:46, "Zden?k Tron??ek" a ?crit : > To me it seems logical that filter() returns the same collection as was > the original collection. For Set you do not have any other choice either: > > set.filter(predicate) > > cannot switch from HashSet to TreeSet or back. > > Z. How do you implement that ? R. From tronicek at fit.cvut.cz Thu Mar 10 03:18:18 2011 From: tronicek at fit.cvut.cz (=?utf-8?B?IlpkZW7Em2sgVHJvbsOtxI1layI=?=) Date: Thu, 10 Mar 2011 12:18:18 +0100 Subject: Design for collections upgrades In-Reply-To: <4D78B049.7000907@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78B049.7000907@univ-mlv.fr> Message-ID: <4ccfbc5c8a278705a3e9a0f2cfd8863a.squirrel@imap.fit.cvut.cz> I have not being thinking of it. The first idea is: Class c = (Class) set.getClass(); Set newSet = c.newInstance(); Z. -- Zdenek Tronicek FIT CTU in Prague R?mi Forax napsal(a): > Le 10/03/2011 11:46, "Zden?k Tron??ek" a ?crit : >> To me it seems logical that filter() returns the same collection as was >> the original collection. For Set you do not have any other choice >> either: >> >> set.filter(predicate) >> >> cannot switch from HashSet to TreeSet or back. >> >> Z. > > How do you implement that ? > > R. > > > From alessiostalla at gmail.com Thu Mar 10 03:32:45 2011 From: alessiostalla at gmail.com (Alessio Stalla) Date: Thu, 10 Mar 2011 12:32:45 +0100 Subject: Design for collections upgrades In-Reply-To: <4D78B049.7000907@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78B049.7000907@univ-mlv.fr> Message-ID: On Thu, Mar 10, 2011 at 12:04 PM, R?mi Forax wrote: > ?Le 10/03/2011 11:46, "Zden?k Tron??ek" a ?crit : >> To me it seems logical that filter() returns the same collection as was >> the original collection. For Set you do not have any other choice either: >> >> set.filter(predicate) >> >> cannot switch from HashSet to TreeSet or back. >> >> Z. > > How do you implement that ? Well, extension methods are polymorphic, is that right? Then, you could have a different extension method per Set implementation, and a default one for Set that uses HashSet. If such an extension method existed, it should not be tied to filter in particular; I'm thinking of a generic newInstance() method. It could in fact be generalized for Collection. Alessio From scolebourne at joda.org Thu Mar 10 03:57:48 2011 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 10 Mar 2011 11:57:48 +0000 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> Message-ID: The point I was trying to make is that to me the method name "filter" means filter this collection in place, not return a new copy that is filtered. Just like Collections.sort, shuffle or swap. Its the active tense that implies it. I also think that Java is a mutation based language in developers minds, and if you asked around then that in-place change is what would be expected. Now, the FP viewpoint suggests thats a bad idea, and the presence of immutable collections makes it hard to implement, but that doesn't change what I perceive developers would currently expect from that method name and similar actve tense ones. Finally, I'd argue against using "map" as a method name in Java, given the strong connection to the entirely different concept of the Map interface. Stephen 2011/3/10 "Zden?k Tron??ek" : > To me it seems logical that filter() returns the same collection as was > the original collection. For Set you do not have any other choice either: > > set.filter(predicate) > > cannot switch from HashSet to TreeSet or back. > > Z. > -- > Zdenek Tronicek > FIT CTU in Prague > > > R?mi Forax napsal(a): >> >> ? ? ?List ?things = ... >> ? ? ?Collection ?fooAbles = things.filter(#Thing.isFoo); // ooh, >> pretty >> >> >> Not that pretty because filter have to create a new collection and >> there is no way to do that apart hard coding a new ArrayList somewhere. >> >> It's better in my opinion to have a filterTo that takes a collection >> as argument. >> >> Collection ?fooAbles = things.filterTo(#Thing.isFoo, new >> HashSet<>()); >> >> >> R?mi >> >> On 03/08/2011 06:23 PM, Brian Goetz wrote: >>> Since people are already discussing this based on an experimental >>> checkin, let me outline the big picture plan here. >>> >>> The general idea is to add functional-like operations to collections -- >>> filter, map, reduce, apply. >>> >>> I see three sensible modes, with explicit choices of which you get. >>> >>> 1. ?Serial / Eager. ?This is the straight >>> collections-with-functional-style mode, and some samples have already >>> been checked in as proof of concept. ?Operations on collections yield >>> new collections, and you can chain the calls. ?It values ease of use >>> over performance (no new concepts like laziness), but the performance >>> model is still highly predictable. ?You get things like >>> >>> ? ? ? ?Collection fooAbles = things.filter( #{ t -> ?t.isFoo() }); >>> >>> or, with method references: >>> >>> ? ? ? ?Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty >>> >>> You can also chain calls together, though you pay a (predictable) >>> performance cost of intermediate collections, which for small >>> collections is unlikely to matter: >>> >>> ? ? ? ?maxFooWeight = things.filter(#Thing.isFoo) >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? .map(#Thing.getWeight) >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? .max(); >>> >>> The benefit here is concision and clarity. ?The cost is some >>> performance, but maybe not so much that people freak out. ?If people >>> care, they move to the next model, which is: >>> >>> 2. ?Serial / Lazy. ?Here, the primary abstraction is Stream (name to be >>> chosen later, Remi used "lazy" in his example.) ?To transfer between >>> "eager world" and "lazy world", you use conversion methods (toStream / >>> toCollection). ?A typical call chain probably looks like: >>> ? ? collection.toStream / op / op / op / {toCollection,reduce,apply} >>> >>> so the above example becomes >>> >>> ? ? ? ?maxFooWeight = things.asStream() >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? .filter(#Thing.isFoo) >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? .map(#Thing.getWeight) >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? .max(); >>> >>> The return type of Collection.filter is different from the return type >>> of Stream.filter, so the choice and performance costs are reflected in >>> the static type system. ?This avoids the cost of the intermediate >>> collections, but is still serial. ?If you care about that, you move up >>> to the next model, which is: >>> >>> 3. ?Parallel / Lazy. ?Here, the primary abstraction is something like >>> ParallelStream or ParallelIterable. ?Let's call it ParallelFoo to avoid >>> bikeshedding for the moment. ?Now, the code looks like: >>> >>> ? ? ? ?maxFooWeight = things.asParallelFoo() >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? .filter(#Thing.isFoo) >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? .map(#Thing.getWeight) >>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? .max(); >>> >>> Again, the return type of ParallelFoo.filter is different from >>> Stream.filter or Collection.filter, so again the choice is reflected in >>> the static type system. ?But you don't have to rewrite your code. >>> >>> The beauty here is twofold: >>> >>> ? ?- The base model (serial/eager) is easy to understand and natural to >>> use as a way of expressing what the programmer wants to do, and >>> attractive enough to stand on its own -- just a little slow with big >>> collections. >>> ? ?- Switching between execution models is mostly a matter of adding an >>> explicit conversion or two in the call chain, as the models are similar >>> enough that the rest of the code should still work (and even mean the >>> same thing.) >>> >>> >>> On 3/8/2011 8:43 AM, R?mi Forax wrote: >>>> ? ? Le 08/03/2011 14:31, Jim Mayer a ?crit : >>>>> // I can tolerate this one >>>>> ? ? ? ?long product(List ? ?list) { >>>>> ? ? ? ? ?return list.map(#{x -> ? ?(long) x}).reduce(0L, #{sum, x -> >>>>> ?sum * x}); >>>>> ? ? ? ?} >>>> I prefer this one: >>>> >>>> ? ? ?long product(List ? ?list) { >>>> ? ? ? ? ?return list.lazy().map(#{x -> ? ?(long) x}).reduce(0L, #{sum, >>>> x -> ? ?sum * x}); >>>> ? ? ?} >>>> >>>> lazy() means, don't do map directly, but wait and do map and reduce in >>>> one iteration. >>>> >>>> R?mi >>>> >>>> >> >> >> > > > From peter.levart at marand.si Thu Mar 10 04:10:38 2011 From: peter.levart at marand.si (Peter Levart) Date: Thu, 10 Mar 2011 13:10:38 +0100 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: <4D7665FB.5070209@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: <201103101310.38531.peter.levart@marand.si> On 03/08/11, Brian Goetz wrote: > 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be > chosen later, Remi used "lazy" in his example.) To transfer between > "eager world" and "lazy world", you use conversion methods (toStream / > toCollection). A typical call chain probably looks like: > collection.toStream / op / op / op / {toCollection,reduce,apply} > > so the above example becomes > > maxFooWeight = things.asStream() > .filter(#Thing.isFoo) > .map(#Thing.getWeight) > .max(); Is there a need for new type "Stream" other than to be able to position it at a more "appropriate" place in types hierarchy? Is Stream going to be any different from java.lang.Iterable from API perspective? Maybe we don't need another type. Collections framework choose not to staticaly differentiate between mutable and immutable collections which has prooven to be usefull in lots of ways. More types make APIs less interoperable. I've played with the following idea and I think it could more or less satisfy a large specrtum of use-cases and users: Let Iterable by default (via defender methods) be lazy but let Collection (also via defender methods) override the same methods an make them eager. Also privide two methods to switch between eager and lazy on the Iterable itself (and override in Collection and subtypes). This way you get the same usage pattern for Collections (eager by default) and we don't need another type. To express this more clearly, I provide sample Iterable/Collection/List/Set interfaces: public interface Iterable { Iterator iterator(); // eager/lazy switching // iterables are by default lazy (unless overriden by a subtype such as Collection) Iterable toLazy(); // default Defenders.iterableToSelf; // collect to ArrayList by default Collection toEager(); // default Defenders.iterableToArrayList; // lazy filter/map... Iterable filter(Predicate predicate) default Defenders.iterableLazyFilter; Iterable map(Mapper mapper) default Defenders.iterableLazyMap; // collecting/filtering/mapping to provided instance > C addTo(C collection) default Defenders.iterableAddTo; > C filterTo(C collection) default Defenders.iterableFilterTo; > C mapTo(C collection) default Defenders.iterableMapTo; } public interface Collection extends Iterable { // Collection methods // ... // eager/lazy switching // wrap with lazy iterable Iterable toLazy() default Defenders.iterableWrapWithLazyIterable; // collections are eager by default Collection toEager() default Defenders.iterableToSelf; // overriden by covariant and eager filter/map... Collection filter(Predicate predicate) default Defenders.iterableFilterToArrayList; Collection map(Mapper mapper) default Defenders.iterableMapToArrayList; } public interface List extends Collection { // List methods // ... // eager/lazy switching // override with covariant return List toEager(); // default Defenders.iterableToSelf; // eager filter/map... // override with covariant return List filter(Predicate predicate); // default Defenders.iterableFilterToArrayList; // override with covariant return List map(Mapper mapper); // default Defenders.iterableMapToArrayList; } public interface Set extends Collection { // Set methods // ... // eager/lazy switching // override with covariant return Set toEager(); // default Defenders.iterableToSelf; // eager filter/map... // override with covariant return Set filter(Predicate predicate); // default Defenders.iterableFilterToHashSet; // override with covariant return Set map(Mapper mapper); // default Defenders.iterableMapToHashSet; } ...and for completeness, here is also the signatures of Defenders static methods: public class Defenders { // lazy/eager wraping/conversion public static > I iterableToSelf(I self) public static Iterable iterableWrapWithLazyIterable(Iterable self) public static List iterableToArrayList(Iterable self) public static Set iterableToHashSet(Iterable self) // eager filter/map public static Collection iterableFilterToArrayList(Iterable self, Predicate predicate) public static Collection iterableMapToArrayList(Iterable self, Mapper mapper) public static Set iterableFilterToHashSet(Iterable self, Predicate predicate) public static Set iterableMapToHashSet(Iterable self, Mapper mapper) // lazy filter/map public static Iterable iterableLazyFilter(final Iterable self, final Predicate predicate) public static Iterable iterableLazyMap(final Iterable self, final Mapper mapper) // collecting/filtering/mapping to provided instance public static > C iterableAddTo(Iterable self, C targetCollection) public static > C iterableFilterTo(Iterable self, Predicate predicate, C targetCollection) public static > C iterableMapTo(Iterable self, Mapper mapper, C targetCollection) } Regards, Peter From peter.levart at marand.si Thu Mar 10 04:19:53 2011 From: peter.levart at marand.si (Peter Levart) Date: Thu, 10 Mar 2011 13:19:53 +0100 Subject: Design for collections upgrades In-Reply-To: References: <4D76869C.7010203@univ-mlv.fr> Message-ID: <201103101319.53560.peter.levart@marand.si> On 03/10/11, Zden?k Tron??ek wrote: > To me it seems logical that filter() returns the same collection as was > the original collection. But that is rarely what you want by default. The eager result you get from filter() is usualy just an intermediate representation of some data. Think of this, for example: ConcurrentMap cMap = ...; Set someKeys = cMap.keys().filter(...); Would you usually want someKeys to be backed by a separate instance of ConcurrentHashMap? Peter > For Set you do not have any other choice either: > > set.filter(predicate) > > cannot switch from HashSet to TreeSet or back. > > Z. > > > > List things = ... > > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, > > pretty > > > > > > Not that pretty because filter have to create a new collection and > > there is no way to do that apart hard coding a new ArrayList somewhere. > > > > It's better in my opinion to have a filterTo that takes a collection > > as argument. > > > > Collection fooAbles = things.filterTo(#Thing.isFoo, new > > HashSet<>()); > > > > > > R?mi > > > > On 03/08/2011 06:23 PM, Brian Goetz wrote: > >> Since people are already discussing this based on an experimental > >> checkin, let me outline the big picture plan here. > >> > >> The general idea is to add functional-like operations to collections -- > >> filter, map, reduce, apply. > >> > >> I see three sensible modes, with explicit choices of which you get. > >> > >> 1. Serial / Eager. This is the straight > >> collections-with-functional-style mode, and some samples have already > >> been checked in as proof of concept. Operations on collections yield > >> new collections, and you can chain the calls. It values ease of use > >> over performance (no new concepts like laziness), but the performance > >> model is still highly predictable. You get things like > >> > >> Collection fooAbles = things.filter( #{ t -> t.isFoo() }); > >> > >> or, with method references: > >> > >> Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty > >> > >> You can also chain calls together, though you pay a (predictable) > >> performance cost of intermediate collections, which for small > >> collections is unlikely to matter: > >> > >> maxFooWeight = things.filter(#Thing.isFoo) > >> .map(#Thing.getWeight) > >> .max(); > >> > >> The benefit here is concision and clarity. The cost is some > >> performance, but maybe not so much that people freak out. If people > >> care, they move to the next model, which is: > >> > >> 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be > >> chosen later, Remi used "lazy" in his example.) To transfer between > >> "eager world" and "lazy world", you use conversion methods (toStream / > >> toCollection). A typical call chain probably looks like: > >> collection.toStream / op / op / op / {toCollection,reduce,apply} > >> > >> so the above example becomes > >> > >> maxFooWeight = things.asStream() > >> .filter(#Thing.isFoo) > >> .map(#Thing.getWeight) > >> .max(); > >> > >> The return type of Collection.filter is different from the return type > >> of Stream.filter, so the choice and performance costs are reflected in > >> the static type system. This avoids the cost of the intermediate > >> collections, but is still serial. If you care about that, you move up > >> to the next model, which is: > >> > >> 3. Parallel / Lazy. Here, the primary abstraction is something like > >> ParallelStream or ParallelIterable. Let's call it ParallelFoo to avoid > >> bikeshedding for the moment. Now, the code looks like: > >> > >> maxFooWeight = things.asParallelFoo() > >> .filter(#Thing.isFoo) > >> .map(#Thing.getWeight) > >> .max(); > >> > >> Again, the return type of ParallelFoo.filter is different from > >> Stream.filter or Collection.filter, so again the choice is reflected in > >> the static type system. But you don't have to rewrite your code. > >> > >> The beauty here is twofold: > >> > >> - The base model (serial/eager) is easy to understand and natural to > >> use as a way of expressing what the programmer wants to do, and > >> attractive enough to stand on its own -- just a little slow with big > >> collections. > >> - Switching between execution models is mostly a matter of adding an > >> explicit conversion or two in the call chain, as the models are similar > >> enough that the rest of the code should still work (and even mean the > >> same thing.) > >> > >> > >> On 3/8/2011 8:43 AM, R?mi Forax wrote: > >>> Le 08/03/2011 14:31, Jim Mayer a ?crit : > >>>> // I can tolerate this one > >>>> long product(List list) { > >>>> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> > >>>> sum * x}); > >>>> } > >>> I prefer this one: > >>> > >>> long product(List list) { > >>> return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, > >>> x -> sum * x}); > >>> } > >>> > >>> lazy() means, don't do map directly, but wait and do map and reduce in > >>> one iteration. > >>> > >>> R?mi > >>> > >>> > > > > > > > > > From peter.levart at marand.si Thu Mar 10 04:52:15 2011 From: peter.levart at marand.si (Peter Levart) Date: Thu, 10 Mar 2011 13:52:15 +0100 Subject: Design for collections upgrades - correction In-Reply-To: <201103101310.38531.peter.levart@marand.si> References: <4D7665FB.5070209@oracle.com> <201103101310.38531.peter.levart@marand.si> Message-ID: <201103101352.15195.peter.levart@marand.si> On 03/10/11, Peter Levart wrote: > > > public interface Iterable > { > Iterator iterator(); > > // eager/lazy switching > > // iterables are by default lazy (unless overriden by a subtype such as Collection) > Iterable toLazy(); // default Defenders.iterableToSelf; > > // collect to ArrayList by default > Collection toEager(); // default Defenders.iterableToArrayList; > > // lazy filter/map... > > Iterable filter(Predicate predicate) default Defenders.iterableLazyFilter; > > Iterable map(Mapper mapper) default Defenders.iterableLazyMap; > > // collecting/filtering/mapping to provided instance > > > C addTo(C collection) default Defenders.iterableAddTo; > The last two defender methods: > > C filterTo(C collection) default Defenders.iterableFilterTo; > > > C mapTo(C collection) default Defenders.iterableMapTo; ...should have been writen as: > C filterTo(Predicate predicate, C collection); // default Defenders.iterableFilterTo; > C mapTo(Mapper mapper, C collection); // default Defenders.iterableMapTo; > } Peter From forax at univ-mlv.fr Thu Mar 10 05:57:31 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Thu, 10 Mar 2011 14:57:31 +0100 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> Message-ID: <4D78D8CB.4020801@univ-mlv.fr> Yes, we need to provide methods that filter/map directly the content of a collections. But I don't think it's a good idea to name them filter or map. Why not filterAll and mapAll ? R?mi Le 10/03/2011 12:57, Stephen Colebourne a ?crit : > The point I was trying to make is that to me the method name "filter" > means filter this collection in place, not return a new copy that is > filtered. Just like Collections.sort, shuffle or swap. Its the active > tense that implies it. > > I also think that Java is a mutation based language in developers > minds, and if you asked around then that in-place change is what would > be expected. Now, the FP viewpoint suggests thats a bad idea, and the > presence of immutable collections makes it hard to implement, but that > doesn't change what I perceive developers would currently expect from > that method name and similar actve tense ones. > > Finally, I'd argue against using "map" as a method name in Java, given > the strong connection to the entirely different concept of the Map > interface. > > Stephen > > > 2011/3/10 "Zden?k Tron??ek": >> To me it seems logical that filter() returns the same collection as was >> the original collection. For Set you do not have any other choice either: >> >> set.filter(predicate) >> >> cannot switch from HashSet to TreeSet or back. >> >> Z. >> -- >> Zdenek Tronicek >> FIT CTU in Prague >> >> >> R?mi Forax napsal(a): >>> List things = ... >>> Collection fooAbles = things.filter(#Thing.isFoo); // ooh, >>> pretty >>> >>> >>> Not that pretty because filter have to create a new collection and >>> there is no way to do that apart hard coding a new ArrayList somewhere. >>> >>> It's better in my opinion to have a filterTo that takes a collection >>> as argument. >>> >>> Collection fooAbles = things.filterTo(#Thing.isFoo, new >>> HashSet<>()); >>> >>> >>> R?mi >>> >>> On 03/08/2011 06:23 PM, Brian Goetz wrote: >>>> Since people are already discussing this based on an experimental >>>> checkin, let me outline the big picture plan here. >>>> >>>> The general idea is to add functional-like operations to collections -- >>>> filter, map, reduce, apply. >>>> >>>> I see three sensible modes, with explicit choices of which you get. >>>> >>>> 1. Serial / Eager. This is the straight >>>> collections-with-functional-style mode, and some samples have already >>>> been checked in as proof of concept. Operations on collections yield >>>> new collections, and you can chain the calls. It values ease of use >>>> over performance (no new concepts like laziness), but the performance >>>> model is still highly predictable. You get things like >>>> >>>> Collection fooAbles = things.filter( #{ t -> t.isFoo() }); >>>> >>>> or, with method references: >>>> >>>> Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty >>>> >>>> You can also chain calls together, though you pay a (predictable) >>>> performance cost of intermediate collections, which for small >>>> collections is unlikely to matter: >>>> >>>> maxFooWeight = things.filter(#Thing.isFoo) >>>> .map(#Thing.getWeight) >>>> .max(); >>>> >>>> The benefit here is concision and clarity. The cost is some >>>> performance, but maybe not so much that people freak out. If people >>>> care, they move to the next model, which is: >>>> >>>> 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be >>>> chosen later, Remi used "lazy" in his example.) To transfer between >>>> "eager world" and "lazy world", you use conversion methods (toStream / >>>> toCollection). A typical call chain probably looks like: >>>> collection.toStream / op / op / op / {toCollection,reduce,apply} >>>> >>>> so the above example becomes >>>> >>>> maxFooWeight = things.asStream() >>>> .filter(#Thing.isFoo) >>>> .map(#Thing.getWeight) >>>> .max(); >>>> >>>> The return type of Collection.filter is different from the return type >>>> of Stream.filter, so the choice and performance costs are reflected in >>>> the static type system. This avoids the cost of the intermediate >>>> collections, but is still serial. If you care about that, you move up >>>> to the next model, which is: >>>> >>>> 3. Parallel / Lazy. Here, the primary abstraction is something like >>>> ParallelStream or ParallelIterable. Let's call it ParallelFoo to avoid >>>> bikeshedding for the moment. Now, the code looks like: >>>> >>>> maxFooWeight = things.asParallelFoo() >>>> .filter(#Thing.isFoo) >>>> .map(#Thing.getWeight) >>>> .max(); >>>> >>>> Again, the return type of ParallelFoo.filter is different from >>>> Stream.filter or Collection.filter, so again the choice is reflected in >>>> the static type system. But you don't have to rewrite your code. >>>> >>>> The beauty here is twofold: >>>> >>>> - The base model (serial/eager) is easy to understand and natural to >>>> use as a way of expressing what the programmer wants to do, and >>>> attractive enough to stand on its own -- just a little slow with big >>>> collections. >>>> - Switching between execution models is mostly a matter of adding an >>>> explicit conversion or two in the call chain, as the models are similar >>>> enough that the rest of the code should still work (and even mean the >>>> same thing.) >>>> >>>> >>>> On 3/8/2011 8:43 AM, R?mi Forax wrote: >>>>> Le 08/03/2011 14:31, Jim Mayer a ?crit : >>>>>> // I can tolerate this one >>>>>> long product(List list) { >>>>>> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> >>>>>> sum * x}); >>>>>> } >>>>> I prefer this one: >>>>> >>>>> long product(List list) { >>>>> return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, >>>>> x -> sum * x}); >>>>> } >>>>> >>>>> lazy() means, don't do map directly, but wait and do map and reduce in >>>>> one iteration. >>>>> >>>>> R?mi >>>>> >>>>> >>> >>> >> >> From forax at univ-mlv.fr Thu Mar 10 06:00:15 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 10 Mar 2011 15:00:15 +0100 Subject: Design for collections upgrades In-Reply-To: <201103101310.38531.peter.levart@marand.si> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <201103101310.38531.peter.levart@marand.si> Message-ID: <4D78D96F.4070907@univ-mlv.fr> Le 10/03/2011 13:10, Peter Levart a ?crit : > Let Iterable by default (via defender methods) be lazy but let Collection (also via defender methods) override the same methods an make them eager. Also privide two methods to switch between eager and lazy on the Iterable itself (and override in Collection and subtypes). If Collection.filter overrides Iterable.filter, they should have the same semantics. And as I already say, how to implement toEager() ? R?mi From forax at univ-mlv.fr Thu Mar 10 06:02:27 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Thu, 10 Mar 2011 15:02:27 +0100 Subject: Design for collections upgrades In-Reply-To: <201103101319.53560.peter.levart@marand.si> References: <4D76869C.7010203@univ-mlv.fr> <201103101319.53560.peter.levart@marand.si> Message-ID: <4D78D9F3.8000002@univ-mlv.fr> Le 10/03/2011 13:19, Peter Levart a ?crit : > On 03/10/11, Zden?k Tron??ek wrote: >> > To me it seems logical that filter() returns the same collection as was >> > the original collection. > But that is rarely what you want by default. The eager result you get from filter() is usualy just an intermediate representation of some data. Think of this, for example: > > ConcurrentMap cMap = ...; > > Set someKeys = cMap.keys().filter(...); > > > Would you usually want someKeys to be backed by a separate instance of ConcurrentHashMap? > > Peter Peter, I have some problem to understand what is your position. Does cMap.keys().filter(...) return a set or an iterable ? R?mi From ssullivan at aptima.com Thu Mar 10 06:18:40 2011 From: ssullivan at aptima.com (Seamus Sullivan) Date: Thu, 10 Mar 2011 09:18:40 -0500 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> Message-ID: <002701cbdf2e$0e98dda0$2bca98e0$@com> Regarding 'map' - this should be a very frequently used method; it seems likely that there will be a bit of confusion between the interface and the method in discussions. I would suggest using C++'s standard template library name for the similar function: 'transform' to avoid conflating the two. Regarding altering the original collection: this seems like a bad idea. From my experience using the STL's remove functions, I had to frequently make temporary copies of collections prior to filtering (remove_if) so that collections wouldn't be altered for further/different processing at later stages. Yes, after a while I should have caught on and created my own versions of remove_* that did just that. Seamus -----Original Message----- From: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Stephen Colebourne Sent: Thursday, March 10, 2011 6:58 AM To: lambda-dev Subject: Re: Design for collections upgrades The point I was trying to make is that to me the method name "filter" means filter this collection in place, not return a new copy that is filtered. Just like Collections.sort, shuffle or swap. Its the active tense that implies it. I also think that Java is a mutation based language in developers minds, and if you asked around then that in-place change is what would be expected. Now, the FP viewpoint suggests thats a bad idea, and the presence of immutable collections makes it hard to implement, but that doesn't change what I perceive developers would currently expect from that method name and similar actve tense ones. Finally, I'd argue against using "map" as a method name in Java, given the strong connection to the entirely different concept of the Map interface. Stephen 2011/3/10 "Zden?k Tron??ek" : > To me it seems logical that filter() returns the same collection as was > the original collection. For Set you do not have any other choice either: > > set.filter(predicate) > > cannot switch from HashSet to TreeSet or back. > > Z. > -- > Zdenek Tronicek > FIT CTU in Prague > > > R?mi Forax napsal(a): >> >> List things = ... >> Collection fooAbles = things.filter(#Thing.isFoo); // ooh, >> pretty >> >> >> Not that pretty because filter have to create a new collection and >> there is no way to do that apart hard coding a new ArrayList somewhere. >> >> It's better in my opinion to have a filterTo that takes a collection >> as argument. >> >> Collection fooAbles = things.filterTo(#Thing.isFoo, new >> HashSet<>()); >> >> >> R?mi >> >> On 03/08/2011 06:23 PM, Brian Goetz wrote: >>> Since people are already discussing this based on an experimental >>> checkin, let me outline the big picture plan here. >>> >>> The general idea is to add functional-like operations to collections -- >>> filter, map, reduce, apply. >>> >>> I see three sensible modes, with explicit choices of which you get. >>> >>> 1. Serial / Eager. This is the straight >>> collections-with-functional-style mode, and some samples have already >>> been checked in as proof of concept. Operations on collections yield >>> new collections, and you can chain the calls. It values ease of use >>> over performance (no new concepts like laziness), but the performance >>> model is still highly predictable. You get things like >>> >>> Collection fooAbles = things.filter( #{ t -> t.isFoo() }); >>> >>> or, with method references: >>> >>> Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty >>> >>> You can also chain calls together, though you pay a (predictable) >>> performance cost of intermediate collections, which for small >>> collections is unlikely to matter: >>> >>> maxFooWeight = things.filter(#Thing.isFoo) >>> .map(#Thing.getWeight) >>> .max(); >>> >>> The benefit here is concision and clarity. The cost is some >>> performance, but maybe not so much that people freak out. If people >>> care, they move to the next model, which is: >>> >>> 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be >>> chosen later, Remi used "lazy" in his example.) To transfer between >>> "eager world" and "lazy world", you use conversion methods (toStream / >>> toCollection). A typical call chain probably looks like: >>> collection.toStream / op / op / op / {toCollection,reduce,apply} >>> >>> so the above example becomes >>> >>> maxFooWeight = things.asStream() >>> .filter(#Thing.isFoo) >>> .map(#Thing.getWeight) >>> .max(); >>> >>> The return type of Collection.filter is different from the return type >>> of Stream.filter, so the choice and performance costs are reflected in >>> the static type system. This avoids the cost of the intermediate >>> collections, but is still serial. If you care about that, you move up >>> to the next model, which is: >>> >>> 3. Parallel / Lazy. Here, the primary abstraction is something like >>> ParallelStream or ParallelIterable. Let's call it ParallelFoo to avoid >>> bikeshedding for the moment. Now, the code looks like: >>> >>> maxFooWeight = things.asParallelFoo() >>> .filter(#Thing.isFoo) >>> .map(#Thing.getWeight) >>> .max(); >>> >>> Again, the return type of ParallelFoo.filter is different from >>> Stream.filter or Collection.filter, so again the choice is reflected in >>> the static type system. But you don't have to rewrite your code. >>> >>> The beauty here is twofold: >>> >>> - The base model (serial/eager) is easy to understand and natural to >>> use as a way of expressing what the programmer wants to do, and >>> attractive enough to stand on its own -- just a little slow with big >>> collections. >>> - Switching between execution models is mostly a matter of adding an >>> explicit conversion or two in the call chain, as the models are similar >>> enough that the rest of the code should still work (and even mean the >>> same thing.) >>> >>> >>> On 3/8/2011 8:43 AM, R?mi Forax wrote: >>>> Le 08/03/2011 14:31, Jim Mayer a ?crit : >>>>> // I can tolerate this one >>>>> long product(List list) { >>>>> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> >>>>> sum * x}); >>>>> } >>>> I prefer this one: >>>> >>>> long product(List list) { >>>> return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, >>>> x -> sum * x}); >>>> } >>>> >>>> lazy() means, don't do map directly, but wait and do map and reduce in >>>> one iteration. >>>> >>>> R?mi >>>> >>>> >> >> >> > > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. From isidore at setgame.com Thu Mar 10 06:27:24 2011 From: isidore at setgame.com (Llewellyn Falco) Date: Thu, 10 Mar 2011 06:27:24 -0800 Subject: Design for collections upgrades In-Reply-To: <4D78D9F3.8000002@univ-mlv.fr> References: <4D76869C.7010203@univ-mlv.fr> <201103101319.53560.peter.levart@marand.si> <4D78D9F3.8000002@univ-mlv.fr> Message-ID: Stop. Iterable filter(Predicate p) is the method. It should not and can not do the following Set s = myset.filter( #{s->s > 3} ) why? because you can't change the signature to return a Set. You could make it so you have this Set s = (Set)myset.filter( #{s->s > 3} ) but then you run into the following with map assertEqual(3, new Set("a","b","c").map( #s-> s.length() ).count()) how are you going to get that spec to pass? or will map do a fundamentally different thing than filter? Llewellyn From isidore at setgame.com Thu Mar 10 06:30:02 2011 From: isidore at setgame.com (Llewellyn Falco) Date: Thu, 10 Mar 2011 06:30:02 -0800 Subject: Design for collections upgrades In-Reply-To: <002701cbdf2e$0e98dda0$2bca98e0$@com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <002701cbdf2e$0e98dda0$2bca98e0$@com> Message-ID: if you are going to change the names, use the sql select where groupBy they make sense, everybody already understands them, they avoid the issue of wether or not the modify the orignal object. Llewellyn From peter.levart at marand.si Thu Mar 10 06:42:43 2011 From: peter.levart at marand.si (Peter Levart) Date: Thu, 10 Mar 2011 15:42:43 +0100 Subject: Design for collections upgrades In-Reply-To: <4D78D9F3.8000002@univ-mlv.fr> References: <201103101319.53560.peter.levart@marand.si> <4D78D9F3.8000002@univ-mlv.fr> Message-ID: <201103101542.43737.peter.levart@marand.si> On 03/10/11, R?mi Forax wrote: > Le 10/03/2011 13:19, Peter Levart a ?crit : > > On 03/10/11, Zden?k Tron??ek wrote: > >> > To me it seems logical that filter() returns the same collection as was > >> > the original collection. > > But that is rarely what you want by default. The eager result you get from filter() is usualy just an intermediate representation of some data. Think of this, for example: > > > > ConcurrentMap cMap = ...; > > > > Set someKeys = cMap.keys().filter(...); > > > > > > Would you usually want someKeys to be backed by a separate instance of ConcurrentHashMap? > > > > Peter > > Peter, I have some problem to understand what is your position. > Does cMap.keys().filter(...) return a set or an iterable ? Since Brian's preposition was that Collection and subtypes should by default implement eager operations and that subtypes can specify covariant overloads, the type of Set.filter() method should be as specific as possible for the most of usecases. For operation filter on a Set I would say it could return a Set (implemented as HashSet) but maybe just a Collection (implemented as an ArrayList - that's a matter of what is more useable in majority of usecases). To differentiate it with another method, Set.map should return just a Collection (implemented as an ArrayList). If one want's to dump it into a Set (which may loose duplicates and/or order) one can do so explicitly via a Collection.mapTo(Mapper, Collection) method. Zdenek's preposition that filter() should return the same implementation type of Collection as original Collection is not doable (think of annonymous inner implementations that have no standard constructors and/or reference outer instances of whatever objects). Peter > > R?mi > > > From forax at univ-mlv.fr Thu Mar 10 06:46:21 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 10 Mar 2011 15:46:21 +0100 Subject: Design for collections upgrades In-Reply-To: References: <4D76869C.7010203@univ-mlv.fr> <201103101319.53560.peter.levart@marand.si> <4D78D9F3.8000002@univ-mlv.fr> Message-ID: <4D78E43D.8080305@univ-mlv.fr> Le 10/03/2011 15:27, Llewellyn Falco a ?crit : > Stop. Do you really think you can stop me :) > Iterable filter(Predicate p) > > is the method. I agree but not for the reason below. In fact, it's more: Iterable filter(Filter filter) > It should not and can not do the following > > Set s = myset.filter( #{s->s> 3} ) > > why? because you can't change the signature to return a Set. Java allows covariant return type. So you can. > You could > make it so you have this > > Set s = (Set)myset.filter( #{s->s> 3} ) > > but then you run into the following with map > > assertEqual(3, new Set("a","b","c").map( #s-> s.length() ).count()) > > how are you going to get that spec to pass? > or will map do a fundamentally different thing than filter? yes, map create can create a new collection with a type which is not the type of the original collection. > Llewellyn R?mi From ssullivan at aptima.com Thu Mar 10 06:48:34 2011 From: ssullivan at aptima.com (Seamus Sullivan) Date: Thu, 10 Mar 2011 09:48:34 -0500 Subject: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] In-Reply-To: References: Message-ID: <002d01cbdf32$3b8df8f0$b2a9ead0$@com> The use of fold in functional programming makes perfect sense, as they tend to support tail-call recursion - which has some rather nice performance benefits. To get back on point a bit, the key element of fold in ML (I'm sure it's just as true in other fp languages) is that of the accumulation function performed within the fold - which allows a type transformation to take place - what do you gain by limiting the return type of the binary function? By limiting the return type of the accumulator, the expressiveness of fold is limited, so there is a very definite loss that happens. I have used the accumulate template function in C++'s standard library to perform processing on collections of relatively complex objects that returned relatively simple results: computing the average quality assessment of a collection containing complex data comes to mind - my point is that the transformation from a class of some sort to a primitive type was relatively common inside the fold. Yes, this could have been done in two steps - performing a map and then a simply-typed fold/reduce, but why split this into two iterative operations when it seems natural to think of it as one collective action performed within some sort of loop? I would find it odd to have to iterate twice over every collection I wanted to run a fold operation on. Seamus -----Original Message----- From: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Lawrence Kesteloot Sent: Tuesday, March 08, 2011 3:38 AM To: lambda-dev at openjdk.java.net Subject: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] On Mon, Mar 7, 2011 at 6:30 PM, Neal Gafter wrote: > It would be a shame to ignore [the functional programming community's] experience > and repeat mistakes of the distant past. Their mistake of the distant past was to use fold-left in the first place. > for some simple examples, foldLeft Examples" I assert that every single one of those examples would be more clearly (if more verbosely) expressed as a for-loop. (I tried this myself and it's striking how much clearer the for-loop is, and often more efficient.) I can genuinely see why computer science theorists love fold-left, but it doesn't belong in any code that will later be read by a human. Java should follow the example of Python 3000 and remove fold-left from the API. > Being composed of experts, I expect that the Project Lambda JSR expert group > has members who are well versed in these techniques. I'm hoping for exactly the same thing. Lawrence The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. From forax at univ-mlv.fr Thu Mar 10 06:50:27 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Thu, 10 Mar 2011 15:50:27 +0100 Subject: Design for collections upgrades In-Reply-To: <4D78D8CB.4020801@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> Message-ID: <4D78E533.30307@univ-mlv.fr> Le 10/03/2011 14:57, R?mi Forax a ?crit : > Yes, we need to provide methods that filter/map directly > the content of a collections. > But I don't think it's a good idea to name them filter or map. > > Why not filterAll and mapAll ? > > R?mi To be crystal clear her are the prototypes: boolean filterAll(Filter filter); and boolean mapAll(Mapper mapper); They return true if the collection is modified (like addAll). And mapAll requires that the result type of the mapper is a subtype of the type of the collection. R?mi > Le 10/03/2011 12:57, Stephen Colebourne a ?crit : >> The point I was trying to make is that to me the method name "filter" >> means filter this collection in place, not return a new copy that is >> filtered. Just like Collections.sort, shuffle or swap. Its the active >> tense that implies it. >> >> I also think that Java is a mutation based language in developers >> minds, and if you asked around then that in-place change is what would >> be expected. Now, the FP viewpoint suggests thats a bad idea, and the >> presence of immutable collections makes it hard to implement, but that >> doesn't change what I perceive developers would currently expect from >> that method name and similar actve tense ones. >> >> Finally, I'd argue against using "map" as a method name in Java, given >> the strong connection to the entirely different concept of the Map >> interface. >> >> Stephen >> >> >> 2011/3/10 "Zden?k Tron??ek": >>> To me it seems logical that filter() returns the same collection as was >>> the original collection. For Set you do not have any other choice either: >>> >>> set.filter(predicate) >>> >>> cannot switch from HashSet to TreeSet or back. >>> >>> Z. >>> -- >>> Zdenek Tronicek >>> FIT CTU in Prague >>> >>> >>> R?mi Forax napsal(a): >>>> List things = ... >>>> Collection fooAbles = things.filter(#Thing.isFoo); // ooh, >>>> pretty >>>> >>>> >>>> Not that pretty because filter have to create a new collection and >>>> there is no way to do that apart hard coding a new ArrayList somewhere. >>>> >>>> It's better in my opinion to have a filterTo that takes a collection >>>> as argument. >>>> >>>> Collection fooAbles = things.filterTo(#Thing.isFoo, new >>>> HashSet<>()); >>>> >>>> >>>> R?mi >>>> >>>> On 03/08/2011 06:23 PM, Brian Goetz wrote: >>>>> Since people are already discussing this based on an experimental >>>>> checkin, let me outline the big picture plan here. >>>>> >>>>> The general idea is to add functional-like operations to collections -- >>>>> filter, map, reduce, apply. >>>>> >>>>> I see three sensible modes, with explicit choices of which you get. >>>>> >>>>> 1. Serial / Eager. This is the straight >>>>> collections-with-functional-style mode, and some samples have already >>>>> been checked in as proof of concept. Operations on collections yield >>>>> new collections, and you can chain the calls. It values ease of use >>>>> over performance (no new concepts like laziness), but the performance >>>>> model is still highly predictable. You get things like >>>>> >>>>> Collection fooAbles = things.filter( #{ t -> t.isFoo() }); >>>>> >>>>> or, with method references: >>>>> >>>>> Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty >>>>> >>>>> You can also chain calls together, though you pay a (predictable) >>>>> performance cost of intermediate collections, which for small >>>>> collections is unlikely to matter: >>>>> >>>>> maxFooWeight = things.filter(#Thing.isFoo) >>>>> .map(#Thing.getWeight) >>>>> .max(); >>>>> >>>>> The benefit here is concision and clarity. The cost is some >>>>> performance, but maybe not so much that people freak out. If people >>>>> care, they move to the next model, which is: >>>>> >>>>> 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be >>>>> chosen later, Remi used "lazy" in his example.) To transfer between >>>>> "eager world" and "lazy world", you use conversion methods (toStream / >>>>> toCollection). A typical call chain probably looks like: >>>>> collection.toStream / op / op / op / {toCollection,reduce,apply} >>>>> >>>>> so the above example becomes >>>>> >>>>> maxFooWeight = things.asStream() >>>>> .filter(#Thing.isFoo) >>>>> .map(#Thing.getWeight) >>>>> .max(); >>>>> >>>>> The return type of Collection.filter is different from the return type >>>>> of Stream.filter, so the choice and performance costs are reflected in >>>>> the static type system. This avoids the cost of the intermediate >>>>> collections, but is still serial. If you care about that, you move up >>>>> to the next model, which is: >>>>> >>>>> 3. Parallel / Lazy. Here, the primary abstraction is something like >>>>> ParallelStream or ParallelIterable. Let's call it ParallelFoo to avoid >>>>> bikeshedding for the moment. Now, the code looks like: >>>>> >>>>> maxFooWeight = things.asParallelFoo() >>>>> .filter(#Thing.isFoo) >>>>> .map(#Thing.getWeight) >>>>> .max(); >>>>> >>>>> Again, the return type of ParallelFoo.filter is different from >>>>> Stream.filter or Collection.filter, so again the choice is reflected in >>>>> the static type system. But you don't have to rewrite your code. >>>>> >>>>> The beauty here is twofold: >>>>> >>>>> - The base model (serial/eager) is easy to understand and natural to >>>>> use as a way of expressing what the programmer wants to do, and >>>>> attractive enough to stand on its own -- just a little slow with big >>>>> collections. >>>>> - Switching between execution models is mostly a matter of adding an >>>>> explicit conversion or two in the call chain, as the models are similar >>>>> enough that the rest of the code should still work (and even mean the >>>>> same thing.) >>>>> >>>>> >>>>> On 3/8/2011 8:43 AM, R?mi Forax wrote: >>>>>> Le 08/03/2011 14:31, Jim Mayer a ?crit : >>>>>>> // I can tolerate this one >>>>>>> long product(List list) { >>>>>>> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> >>>>>>> sum * x}); >>>>>>> } >>>>>> I prefer this one: >>>>>> >>>>>> long product(List list) { >>>>>> return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, >>>>>> x -> sum * x}); >>>>>> } >>>>>> >>>>>> lazy() means, don't do map directly, but wait and do map and reduce in >>>>>> one iteration. >>>>>> >>>>>> R?mi >>>>>> >>>>>> >>>> >>> > From int19h at gmail.com Thu Mar 10 10:56:14 2011 From: int19h at gmail.com (Pavel Minaev) Date: Thu, 10 Mar 2011 10:56:14 -0800 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78B049.7000907@univ-mlv.fr> Message-ID: So if I call filter on a TreeSet reference, then I get a TreeSet; but if I upcast it to Set and call filter, I get HashSet? I think it's too subtle, and likely to go unnoticed. Especially since common practice in Java code is to type variables as relaxed as possible, even for locals (i.e. Set rather than TreeSet). This also changes the usual conventions for collection operations, where the precise semantics of the operation is defined by the dynamic type of the collection, not static type of the reference. For example, if I call add() on a List reference which refers to an ArrayList, I know that the element is added to the end of collection, and that complexity is amortized constant time. But with this proposal for filter() etc, that would no longer be true - static type of reference would define behavior. If there's no way to implement it such that it depends only on the dynamic type of object, then I think it would be better to have a single uniform behavior for all collections - and that would have to be lazy, so that you can build eager (with collection type explicitly specified) on top of that. On Thu, Mar 10, 2011 at 3:32 AM, Alessio Stalla wrote: > Well, extension methods are polymorphic, is that right? Then, you > could have a different extension method per Set implementation, and a > default one for Set that uses HashSet. If such an extension method > existed, it should not be tied to filter in particular; I'm thinking > of a generic newInstance() method. It could in fact be generalized for > Collection. > > Alessio > > From forax at univ-mlv.fr Thu Mar 10 10:57:43 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 10 Mar 2011 19:57:43 +0100 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78B049.7000907@univ-mlv.fr> Message-ID: <4D791F27.8010600@univ-mlv.fr> I agree. R?mi On 03/10/2011 07:56 PM, Pavel Minaev wrote: > So if I call filter on a TreeSet reference, then I get a TreeSet; but > if I upcast it to Set and call filter, I get HashSet? > > I think it's too subtle, and likely to go unnoticed. Especially since > common practice in Java code is to type variables as relaxed as > possible, even for locals (i.e. Set rather than TreeSet). > > This also changes the usual conventions for collection operations, > where the precise semantics of the operation is defined by the dynamic > type of the collection, not static type of the reference. For example, > if I call add() on a List reference which refers to an ArrayList, I > know that the element is added to the end of collection, and that > complexity is amortized constant time. But with this proposal for > filter() etc, that would no longer be true - static type of reference > would define behavior. > > If there's no way to implement it such that it depends only on the > dynamic type of object, then I think it would be better to have a > single uniform behavior for all collections - and that would have to > be lazy, so that you can build eager (with collection type explicitly > specified) on top of that. > > > On Thu, Mar 10, 2011 at 3:32 AM, Alessio Stalla > > wrote: > > Well, extension methods are polymorphic, is that right? Then, you > could have a different extension method per Set implementation, and a > default one for Set that uses HashSet. If such an extension method > existed, it should not be tied to filter in particular; I'm thinking > of a generic newInstance() method. It could in fact be generalized for > Collection. > > Alessio > > From sam at sampullara.com Thu Mar 10 11:04:46 2011 From: sam at sampullara.com (Sam Pullara) Date: Thu, 10 Mar 2011 11:04:46 -0800 Subject: Design for collections upgrades In-Reply-To: <4D791F27.8010600@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78B049.7000907@univ-mlv.fr> <4D791F27.8010600@univ-mlv.fr> Message-ID: I also agree. Making these operations eager sort of defeats the purpose of introducing them IMHO. Sam On Mar 10, 2011, at 10:57 AM, R?mi Forax wrote: > I agree. > > R?mi > > On 03/10/2011 07:56 PM, Pavel Minaev wrote: >> So if I call filter on a TreeSet reference, then I get a TreeSet; but >> if I upcast it to Set and call filter, I get HashSet? >> >> I think it's too subtle, and likely to go unnoticed. Especially since >> common practice in Java code is to type variables as relaxed as >> possible, even for locals (i.e. Set rather than TreeSet). >> >> This also changes the usual conventions for collection operations, >> where the precise semantics of the operation is defined by the dynamic >> type of the collection, not static type of the reference. For example, >> if I call add() on a List reference which refers to an ArrayList, I >> know that the element is added to the end of collection, and that >> complexity is amortized constant time. But with this proposal for >> filter() etc, that would no longer be true - static type of reference >> would define behavior. >> >> If there's no way to implement it such that it depends only on the >> dynamic type of object, then I think it would be better to have a >> single uniform behavior for all collections - and that would have to >> be lazy, so that you can build eager (with collection type explicitly >> specified) on top of that. >> >> >> On Thu, Mar 10, 2011 at 3:32 AM, Alessio Stalla >> > wrote: >> >> Well, extension methods are polymorphic, is that right? Then, you >> could have a different extension method per Set implementation, and a >> default one for Set that uses HashSet. If such an extension method >> existed, it should not be tied to filter in particular; I'm thinking >> of a generic newInstance() method. It could in fact be generalized for >> Collection. >> >> Alessio >> >> > > From brian.goetz at oracle.com Thu Mar 10 11:10:42 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 10 Mar 2011 14:10:42 -0500 Subject: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] In-Reply-To: <002d01cbdf32$3b8df8f0$b2a9ead0$@com> References: <002d01cbdf32$3b8df8f0$b2a9ead0$@com> Message-ID: <4D792232.7060105@oracle.com> I think people are getting hung up on the (entry level) serial/eager model, which is largely only an on-ramp. In the serial/lazy model, there is only one iteration as elements stream through the computation, so separating into separate filter/map/reduce steps doesn't really create a "second iteration". In the parallel/lazy model, the same is true: the runtime can identify which operations can be jammed together into a single parallel pass (e.g., filter/map/reduce). On 3/10/2011 9:48 AM, Seamus Sullivan wrote: > The use of fold in functional programming makes perfect sense, as they tend > to support tail-call recursion - which has some rather nice performance > benefits. > > To get back on point a bit, the key element of fold in ML (I'm sure it's > just as true in other fp languages) is that of the accumulation function > performed within the fold - which allows a type transformation to take place > - what do you gain by limiting the return type of the binary function? By > limiting the return type of the accumulator, the expressiveness of fold is > limited, so there is a very definite loss that happens. > > I have used the accumulate template function in C++'s standard library to > perform processing on collections of relatively complex objects that > returned relatively simple results: computing the average quality assessment > of a collection containing complex data comes to mind - my point is that the > transformation from a class of some sort to a primitive type was relatively > common inside the fold. Yes, this could have been done in two steps - > performing a map and then a simply-typed fold/reduce, but why split this > into two iterative operations when it seems natural to think of it as one > collective action performed within some sort of loop? I would find it odd > to have to iterate twice over every collection I wanted to run a fold > operation on. > > Seamus > > -----Original Message----- > From: lambda-dev-bounces at openjdk.java.net > [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Lawrence Kesteloot > Sent: Tuesday, March 08, 2011 3:38 AM > To: lambda-dev at openjdk.java.net > Subject: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] > > On Mon, Mar 7, 2011 at 6:30 PM, Neal Gafter wrote: >> It would be a shame to ignore [the functional programming community's] > experience >> and repeat mistakes of the distant past. > > Their mistake of the distant past was to use fold-left in the first place. > >> for some simple examples,> foldLeft > Examples" ft-examples/> > > I assert that every single one of those examples would be more clearly > (if more verbosely) expressed as a for-loop. (I tried this myself and > it's striking how much clearer the for-loop is, and often more > efficient.) I can genuinely see why computer science theorists love > fold-left, but it doesn't belong in any code that will later be read > by a human. Java should follow the example of Python 3000 and remove > fold-left from the API. > >> Being composed of experts, I expect that the Project Lambda JSR expert > group >> has members who are well versed in these techniques. > > I'm hoping for exactly the same thing. > > Lawrence > > > > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. > > From brian.goetz at oracle.com Thu Mar 10 11:17:58 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 10 Mar 2011 14:17:58 -0500 Subject: Design for collections upgrades In-Reply-To: <4D78D8CB.4020801@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> Message-ID: <4D7923E6.1010601@oracle.com> These are straightforward lambda-taking version of removeAll/retainAll. On the plan. On 3/10/2011 8:57 AM, R??mi Forax wrote: > Yes, we need to provide methods that filter/map directly > the content of a collections. > But I don't think it's a good idea to name them filter or map. > > Why not filterAll and mapAll ? > > R??mi > > Le 10/03/2011 12:57, Stephen Colebourne a ??crit : >> The point I was trying to make is that to me the method name "filter" >> means filter this collection in place, not return a new copy that is >> filtered. Just like Collections.sort, shuffle or swap. Its the active >> tense that implies it. >> >> I also think that Java is a mutation based language in developers >> minds, and if you asked around then that in-place change is what would >> be expected. Now, the FP viewpoint suggests thats a bad idea, and the >> presence of immutable collections makes it hard to implement, but that >> doesn't change what I perceive developers would currently expect from >> that method name and similar actve tense ones. >> >> Finally, I'd argue against using "map" as a method name in Java, given >> the strong connection to the entirely different concept of the Map >> interface. >> >> Stephen >> >> >> 2011/3/10 "Zden??k Tron????ek": >>> To me it seems logical that filter() returns the same collection as was >>> the original collection. For Set you do not have any other choice either: >>> >>> set.filter(predicate) >>> >>> cannot switch from HashSet to TreeSet or back. >>> >>> Z. >>> -- >>> Zdenek Tronicek >>> FIT CTU in Prague >>> >>> >>> R??mi Forax napsal(a): >>>> List things = ... >>>> Collection fooAbles = things.filter(#Thing.isFoo); // ooh, >>>> pretty >>>> >>>> >>>> Not that pretty because filter have to create a new collection and >>>> there is no way to do that apart hard coding a new ArrayList somewhere. >>>> >>>> It's better in my opinion to have a filterTo that takes a collection >>>> as argument. >>>> >>>> Collection fooAbles = things.filterTo(#Thing.isFoo, new >>>> HashSet<>()); >>>> >>>> >>>> R??mi >>>> >>>> On 03/08/2011 06:23 PM, Brian Goetz wrote: >>>>> Since people are already discussing this based on an experimental >>>>> checkin, let me outline the big picture plan here. >>>>> >>>>> The general idea is to add functional-like operations to collections -- >>>>> filter, map, reduce, apply. >>>>> >>>>> I see three sensible modes, with explicit choices of which you get. >>>>> >>>>> 1. Serial / Eager. This is the straight >>>>> collections-with-functional-style mode, and some samples have already >>>>> been checked in as proof of concept. Operations on collections yield >>>>> new collections, and you can chain the calls. It values ease of use >>>>> over performance (no new concepts like laziness), but the performance >>>>> model is still highly predictable. You get things like >>>>> >>>>> Collection fooAbles = things.filter( #{ t -> t.isFoo() }); >>>>> >>>>> or, with method references: >>>>> >>>>> Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty >>>>> >>>>> You can also chain calls together, though you pay a (predictable) >>>>> performance cost of intermediate collections, which for small >>>>> collections is unlikely to matter: >>>>> >>>>> maxFooWeight = things.filter(#Thing.isFoo) >>>>> .map(#Thing.getWeight) >>>>> .max(); >>>>> >>>>> The benefit here is concision and clarity. The cost is some >>>>> performance, but maybe not so much that people freak out. If people >>>>> care, they move to the next model, which is: >>>>> >>>>> 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be >>>>> chosen later, Remi used "lazy" in his example.) To transfer between >>>>> "eager world" and "lazy world", you use conversion methods (toStream / >>>>> toCollection). A typical call chain probably looks like: >>>>> collection.toStream / op / op / op / {toCollection,reduce,apply} >>>>> >>>>> so the above example becomes >>>>> >>>>> maxFooWeight = things.asStream() >>>>> .filter(#Thing.isFoo) >>>>> .map(#Thing.getWeight) >>>>> .max(); >>>>> >>>>> The return type of Collection.filter is different from the return type >>>>> of Stream.filter, so the choice and performance costs are reflected in >>>>> the static type system. This avoids the cost of the intermediate >>>>> collections, but is still serial. If you care about that, you move up >>>>> to the next model, which is: >>>>> >>>>> 3. Parallel / Lazy. Here, the primary abstraction is something like >>>>> ParallelStream or ParallelIterable. Let's call it ParallelFoo to avoid >>>>> bikeshedding for the moment. Now, the code looks like: >>>>> >>>>> maxFooWeight = things.asParallelFoo() >>>>> .filter(#Thing.isFoo) >>>>> .map(#Thing.getWeight) >>>>> .max(); >>>>> >>>>> Again, the return type of ParallelFoo.filter is different from >>>>> Stream.filter or Collection.filter, so again the choice is reflected in >>>>> the static type system. But you don't have to rewrite your code. >>>>> >>>>> The beauty here is twofold: >>>>> >>>>> - The base model (serial/eager) is easy to understand and natural to >>>>> use as a way of expressing what the programmer wants to do, and >>>>> attractive enough to stand on its own -- just a little slow with big >>>>> collections. >>>>> - Switching between execution models is mostly a matter of adding an >>>>> explicit conversion or two in the call chain, as the models are similar >>>>> enough that the rest of the code should still work (and even mean the >>>>> same thing.) >>>>> >>>>> >>>>> On 3/8/2011 8:43 AM, R??mi Forax wrote: >>>>>> Le 08/03/2011 14:31, Jim Mayer a ??crit : >>>>>>> // I can tolerate this one >>>>>>> long product(List list) { >>>>>>> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> >>>>>>> sum * x}); >>>>>>> } >>>>>> I prefer this one: >>>>>> >>>>>> long product(List list) { >>>>>> return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, >>>>>> x -> sum * x}); >>>>>> } >>>>>> >>>>>> lazy() means, don't do map directly, but wait and do map and reduce in >>>>>> one iteration. >>>>>> >>>>>> R??mi >>>>>> >>>>>> >>>> >>>> >>> >>> > > From yshavit at akiban.com Thu Mar 10 11:21:57 2011 From: yshavit at akiban.com (Yuval Shavit) Date: Thu, 10 Mar 2011 14:21:57 -0500 Subject: Design for collections upgrades In-Reply-To: <4D791F27.8010600@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78B049.7000907@univ-mlv.fr> <4D791F27.8010600@univ-mlv.fr> Message-ID: Hi all, I'm just an observer here, and not quite an expert on these issues -- though I am familiar with the concept of lambdas (and looking forward to them, which is why I joined the list). I hope I can provide semi-outsider input. I generally view a new aspect of a language as somewhere to be a bit careful and read at least the javadocs before I get started, so I don't think there's anything wrong with defaulting to lazy evaluation as long as that's specified. Someone familiar with lambdas is going to look for whether they're evaluated lazily or eagerly, and someone who's not is going to be reading the lambdas/filtering/mapping tutorials anyway, so they don't even have to know that eager evaluation is a possibility -- just teach them as a lazy evaluation mechanism. In other words, I wouldn't worry *too* much about confusing people with the lazy/eager distinction. My preference would be a lazy-evaluated Stream which I must explicitly toList/toMap at the end (with an instance of my choosing). If possible, I'd like the toList/Map to be parameterized on the type of instance, so that I can do: HashMap asHash = myStream.toMap( new HashMap() ); TreeMap asHash = myStream.toMap( new TreeMap() ); Thanks, Yuval On Thu, Mar 10, 2011 at 1:57 PM, R?mi Forax wrote: > I agree. > > R?mi > > On 03/10/2011 07:56 PM, Pavel Minaev wrote: > > So if I call filter on a TreeSet reference, then I get a TreeSet; but > > if I upcast it to Set and call filter, I get HashSet? > > > > I think it's too subtle, and likely to go unnoticed. Especially since > > common practice in Java code is to type variables as relaxed as > > possible, even for locals (i.e. Set rather than TreeSet). > > > > This also changes the usual conventions for collection operations, > > where the precise semantics of the operation is defined by the dynamic > > type of the collection, not static type of the reference. For example, > > if I call add() on a List reference which refers to an ArrayList, I > > know that the element is added to the end of collection, and that > > complexity is amortized constant time. But with this proposal for > > filter() etc, that would no longer be true - static type of reference > > would define behavior. > > > > If there's no way to implement it such that it depends only on the > > dynamic type of object, then I think it would be better to have a > > single uniform behavior for all collections - and that would have to > > be lazy, so that you can build eager (with collection type explicitly > > specified) on top of that. > > > > > > On Thu, Mar 10, 2011 at 3:32 AM, Alessio Stalla > > > wrote: > > > > Well, extension methods are polymorphic, is that right? Then, you > > could have a different extension method per Set implementation, and a > > default one for Set that uses HashSet. If such an extension method > > existed, it should not be tied to filter in particular; I'm thinking > > of a generic newInstance() method. It could in fact be generalized > for > > Collection. > > > > Alessio > > > > > > > From alessiostalla at gmail.com Thu Mar 10 11:53:52 2011 From: alessiostalla at gmail.com (Alessio Stalla) Date: Thu, 10 Mar 2011 20:53:52 +0100 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78B049.7000907@univ-mlv.fr> Message-ID: On Thu, Mar 10, 2011 at 7:56 PM, Pavel Minaev wrote: > So if I call filter on a TreeSet reference, then I get a TreeSet; but if I > upcast it to Set and call filter, I get HashSet? No, if I correctly understand how defender methods are supposed to work. Set would have a defender method - say, newInstance() - defaulting to the creation of a HashSet. But TreeSet could actually implement newInstance() to return a TreeSet, perhaps optimized from the current state of the receiver TreeSet instance (e.g. by preallocating enough space to contain the same number of elements as the receiver). This isn't automatically a general mechanism (Set implementations need to implement newInstance() in order to return something different from HashSet), but imho it's a valid point of extension, and all the built-in Set implementations could honor its meaning and document that (the same way as, e.g., all built-in Collection implementations have an empty constructor and a "copy constructor"). Alessio From john at milsson.nu Thu Mar 10 14:29:41 2011 From: john at milsson.nu (John Nilsson) Date: Thu, 10 Mar 2011 23:29:41 +0100 Subject: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] In-Reply-To: <4D792232.7060105@oracle.com> References: <002d01cbdf32$3b8df8f0$b2a9ead0$@com> <4D792232.7060105@oracle.com> Message-ID: What does it mean to map a Set? Let's say I have a set s = {"1+1","2"} does s.map(eval).reduce(+) give me 2 or 4? (Assuming eval and + stands for the obvious) BR, John On Thu, Mar 10, 2011 at 8:10 PM, Brian Goetz wrote: > I think people are getting hung up on the (entry level) serial/eager > model, which is largely only an on-ramp. > > In the serial/lazy model, there is only one iteration as elements stream > through the computation, so separating into separate filter/map/reduce > steps doesn't really create a "second iteration". > > In the parallel/lazy model, the same is true: the runtime can identify > which operations can be jammed together into a single parallel pass > (e.g., filter/map/reduce). > > On 3/10/2011 9:48 AM, Seamus Sullivan wrote: >> The use of fold in functional programming makes perfect sense, as they tend >> to support tail-call recursion - which has some rather nice performance >> benefits. >> >> To get back on point a bit, the key element of fold in ML (I'm sure it's >> just as true in other fp languages) is that of the accumulation function >> performed within the fold - which allows a type transformation to take place >> - what do you gain by limiting the return type of the binary function? ?By >> limiting the return type of the accumulator, the expressiveness of fold is >> limited, so there is a very definite loss that happens. >> >> I have used the accumulate template function in C++'s standard library to >> perform processing on collections of relatively complex objects that >> returned relatively simple results: computing the average quality assessment >> of a collection containing complex data comes to mind - my point is that the >> transformation from a class of some sort to a primitive type was relatively >> common inside the fold. ?Yes, this could have been done in two steps - >> performing a map and then a simply-typed fold/reduce, but why split this >> into two iterative operations when it seems natural to think of it as one >> collective action performed within some sort of loop? ?I would find it odd >> to have to iterate twice over every collection I wanted to run a fold >> operation on. >> >> Seamus >> >> -----Original Message----- >> From: lambda-dev-bounces at openjdk.java.net >> [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Lawrence Kesteloot >> Sent: Tuesday, March 08, 2011 3:38 AM >> To: lambda-dev at openjdk.java.net >> Subject: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] >> >> On Mon, Mar 7, 2011 at 6:30 PM, Neal Gafter ?wrote: >>> It would be a shame to ignore [the functional programming community's] >> experience >>> and repeat mistakes of the distant past. >> >> Their mistake of the distant past was to use fold-left in the first place. >> >>> for some simple examples,>> foldLeft >> Examples"> ft-examples/> >> >> I assert that every single one of those examples would be more clearly >> (if more verbosely) expressed as a for-loop. (I tried this myself and >> it's striking how much clearer the for-loop is, and often more >> efficient.) I can genuinely see why computer science theorists love >> fold-left, but it doesn't belong in any code that will later be read >> by a human. Java should follow the example of Python 3000 and remove >> fold-left from the API. >> >>> Being composed of experts, I expect that the Project Lambda JSR expert >> group >>> has members who are well versed in these techniques. >> >> I'm hoping for exactly the same thing. >> >> Lawrence >> >> >> >> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. >> >> > > From forax at univ-mlv.fr Thu Mar 10 14:44:59 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 10 Mar 2011 23:44:59 +0100 Subject: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] In-Reply-To: References: <002d01cbdf32$3b8df8f0$b2a9ead0$@com> <4D792232.7060105@oracle.com> Message-ID: <4D79546B.2080702@univ-mlv.fr> map() or filter() are defined as using the collection's iterator. so s.map(#eval).reduce(#) => 4 R?mi On 03/10/2011 11:29 PM, John Nilsson wrote: > What does it mean to map a Set? > > Let's say I have a set s = {"1+1","2"} > > does s.map(eval).reduce(+) give me 2 or 4? > > (Assuming eval and + stands for the obvious) > > BR, > John > > On Thu, Mar 10, 2011 at 8:10 PM, Brian Goetz wrote: >> I think people are getting hung up on the (entry level) serial/eager >> model, which is largely only an on-ramp. >> >> In the serial/lazy model, there is only one iteration as elements stream >> through the computation, so separating into separate filter/map/reduce >> steps doesn't really create a "second iteration". >> >> In the parallel/lazy model, the same is true: the runtime can identify >> which operations can be jammed together into a single parallel pass >> (e.g., filter/map/reduce). >> >> On 3/10/2011 9:48 AM, Seamus Sullivan wrote: >>> The use of fold in functional programming makes perfect sense, as they tend >>> to support tail-call recursion - which has some rather nice performance >>> benefits. >>> >>> To get back on point a bit, the key element of fold in ML (I'm sure it's >>> just as true in other fp languages) is that of the accumulation function >>> performed within the fold - which allows a type transformation to take place >>> - what do you gain by limiting the return type of the binary function? By >>> limiting the return type of the accumulator, the expressiveness of fold is >>> limited, so there is a very definite loss that happens. >>> >>> I have used the accumulate template function in C++'s standard library to >>> perform processing on collections of relatively complex objects that >>> returned relatively simple results: computing the average quality assessment >>> of a collection containing complex data comes to mind - my point is that the >>> transformation from a class of some sort to a primitive type was relatively >>> common inside the fold. Yes, this could have been done in two steps - >>> performing a map and then a simply-typed fold/reduce, but why split this >>> into two iterative operations when it seems natural to think of it as one >>> collective action performed within some sort of loop? I would find it odd >>> to have to iterate twice over every collection I wanted to run a fold >>> operation on. >>> >>> Seamus >>> >>> -----Original Message----- >>> From: lambda-dev-bounces at openjdk.java.net >>> [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Lawrence Kesteloot >>> Sent: Tuesday, March 08, 2011 3:38 AM >>> To: lambda-dev at openjdk.java.net >>> Subject: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type] >>> >>> On Mon, Mar 7, 2011 at 6:30 PM, Neal Gafter wrote: >>>> It would be a shame to ignore [the functional programming community's] >>> experience >>>> and repeat mistakes of the distant past. >>> Their mistake of the distant past was to use fold-left in the first place. >>> >>>> for some simple examples,>>> foldLeft >>> Examples">> ft-examples/> >>> >>> I assert that every single one of those examples would be more clearly >>> (if more verbosely) expressed as a for-loop. (I tried this myself and >>> it's striking how much clearer the for-loop is, and often more >>> efficient.) I can genuinely see why computer science theorists love >>> fold-left, but it doesn't belong in any code that will later be read >>> by a human. Java should follow the example of Python 3000 and remove >>> fold-left from the API. >>> >>>> Being composed of experts, I expect that the Project Lambda JSR expert >>> group >>>> has members who are well versed in these techniques. >>> I'm hoping for exactly the same thing. >>> >>> Lawrence >>> >>> >>> >>> The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. >>> >>> >> From brian.goetz at oracle.com Thu Mar 10 15:44:09 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 10 Mar 2011 23:44:09 +0000 Subject: hg: lambda/collections: 32 new changesets Message-ID: <20110310234409.C0EDB4704A@hg.openjdk.java.net> Changeset: 5c4df7e99277 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/5c4df7e99277 Added tag jdk7-b124 for changeset 024a6755895b ! .hgtags Changeset: b566d4909056 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/b566d4909056 Added tag jdk7-b125 for changeset 5c4df7e99277 ! .hgtags Changeset: bd70f76b0309 Author: cl Date: 2011-01-20 15:51 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/bd70f76b0309 Added tag jdk7-b126 for changeset b566d4909056 ! .hgtags Changeset: 6e0f4d6099bb Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/6e0f4d6099bb Added tag jdk7-b127 for changeset bd70f76b0309 ! .hgtags Changeset: f722c246ce71 Author: mchung Date: 2011-01-20 22:16 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/f722c246ce71 7013739: jdk_rmi target is missing in the top repo's test/Makefile Reviewed-by: ohair, igor ! test/Makefile Changeset: 65e6601596e2 Author: lana Date: 2011-01-24 13:21 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/65e6601596e2 Merge Changeset: 61f181d43d9a Author: lana Date: 2011-01-28 10:00 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/61f181d43d9a Merge Changeset: 6db0e6f221bd Author: ohair Date: 2011-01-05 17:24 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/6db0e6f221bd 7009969: Remove SKIP_OPENJDK_BUILD from top Makefile Reviewed-by: robilad ! Makefile ! make/Defs-internal.gmk Changeset: 49c463695059 Author: ohair Date: 2011-01-10 10:00 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/49c463695059 Merge Changeset: 6d9bbcc0a8cb Author: ohair Date: 2011-01-13 17:55 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/6d9bbcc0a8cb Merge Changeset: 24900a58ab9f Author: ohair Date: 2011-01-14 14:04 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/24900a58ab9f 6950375: Remove msvcrt.dll from the Windows JRE bundles Reviewed-by: prr ! Makefile ! README-builds.html Changeset: 3a9f19cbf7f1 Author: ohair Date: 2011-01-26 16:05 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/3a9f19cbf7f1 Merge Changeset: a7a4f6db294d Author: ohair Date: 2011-01-27 18:43 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/a7a4f6db294d Merge Changeset: 57d702105b23 Author: ohair Date: 2011-02-02 09:38 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/57d702105b23 Merge Changeset: 904d7c7c44d9 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/904d7c7c44d9 Added tag jdk7-b128 for changeset 57d702105b23 ! .hgtags Changeset: ce02c0d73d6a Author: ohair Date: 2011-02-03 15:10 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/ce02c0d73d6a 7014634: By default, only build the product bits with a closed jdk build (like openjdk does) Reviewed-by: katleman, cl, igor, trims ! make/Defs-internal.gmk Changeset: e2a214ec8ebc Author: ohair Date: 2011-02-04 07:47 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/e2a214ec8ebc Merge Changeset: a6b015b59fbc Author: ohair Date: 2011-02-08 16:28 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/a6b015b59fbc 7016976: Documentation for required ant version on JDK7 builds on Solaris 10 and Solaris 11 Reviewed-by: rinaldo ! README-builds.html Changeset: cc58c11af154 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/cc58c11af154 Added tag jdk7-b129 for changeset a6b015b59fbc ! .hgtags Changeset: 995077c73fbb Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/995077c73fbb Added tag jdk7-b130 for changeset cc58c11af154 ! .hgtags Changeset: 0fd0aeb592cb Author: jqzuo Date: 2010-12-09 10:58 -0500 URL: http://hg.openjdk.java.net/lambda/collections/rev/0fd0aeb592cb Merge Changeset: 20955959b7b7 Author: jqzuo Date: 2010-12-22 15:55 -0500 URL: http://hg.openjdk.java.net/lambda/collections/rev/20955959b7b7 Merge Changeset: 08fe18caf411 Author: jqzuo Date: 2011-01-10 13:45 -0500 URL: http://hg.openjdk.java.net/lambda/collections/rev/08fe18caf411 Merge Changeset: aee1b0183364 Author: jqzuo Date: 2011-01-24 17:14 -0500 URL: http://hg.openjdk.java.net/lambda/collections/rev/aee1b0183364 Merge Changeset: 12764a5a3aec Author: jqzuo Date: 2011-02-01 15:03 -0500 URL: http://hg.openjdk.java.net/lambda/collections/rev/12764a5a3aec Merge Changeset: df3abd560cbd Author: jqzuo Date: 2011-02-09 16:05 -0500 URL: http://hg.openjdk.java.net/lambda/collections/rev/df3abd560cbd Merge Changeset: e2370dfcc721 Author: paulk Date: 2011-02-14 14:29 -0500 URL: http://hg.openjdk.java.net/lambda/collections/rev/e2370dfcc721 7019371: JDK7 is not building UPX. IFTW wrappers are not compressed. Reviewed-by: billyh, jqzuo ! make/deploy-rules.gmk Changeset: 5466f13d19be Author: jqzuo Date: 2011-02-21 14:18 -0500 URL: http://hg.openjdk.java.net/lambda/collections/rev/5466f13d19be Merge Changeset: da55264ff2fb Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/da55264ff2fb 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 5d86d951426a Author: cl Date: 2011-02-23 15:48 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/5d86d951426a Merge Changeset: 0f62a65fb666 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/lambda/collections/rev/0f62a65fb666 Added tag jdk7-b131 for changeset 5d86d951426a ! .hgtags Changeset: 4a6a3619c7a3 Author: mcimadamore Date: 2011-03-01 17:45 +0000 URL: http://hg.openjdk.java.net/lambda/collections/rev/4a6a3619c7a3 merge with jdk7-b131 From brian.goetz at oracle.com Thu Mar 10 15:44:34 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 10 Mar 2011 23:44:34 +0000 Subject: hg: lambda/collections/corba: 17 new changesets Message-ID: <20110310234447.844B44704B@hg.openjdk.java.net> Changeset: 1ce58c72b789 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/1ce58c72b789 Added tag jdk7-b124 for changeset f90b3e014e83 ! .hgtags Changeset: d7532bcd3742 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/d7532bcd3742 Added tag jdk7-b125 for changeset 1ce58c72b789 ! .hgtags Changeset: 64775e83f4df Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/64775e83f4df Added tag jdk7-b126 for changeset d7532bcd3742 ! .hgtags Changeset: 9baa8f94a11d Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/9baa8f94a11d Added tag jdk7-b127 for changeset 64775e83f4df ! .hgtags Changeset: 3ff9acc7cc06 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/3ff9acc7cc06 Added tag jdk7-b128 for changeset 9baa8f94a11d ! .hgtags Changeset: 6a3903e5b6cc Author: ohair Date: 2011-02-03 15:05 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/6a3903e5b6cc 6944304: Potential rebranding issues in the openjdk7/corba sources Reviewed-by: alanb, mchung, darcy ! src/share/classes/com/sun/corba/se/spi/logging/data/Activation.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/IOR.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Interceptors.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Naming.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/OMG.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/ORBUtil.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/POA.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Util.mc Changeset: 66fa0fcc7792 Author: ohair Date: 2011-02-04 07:47 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/66fa0fcc7792 Merge Changeset: 4cdf9b86f550 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/4cdf9b86f550 Added tag jdk7-b129 for changeset 66fa0fcc7792 ! .hgtags Changeset: 30ecf5c90a30 Author: mfang Date: 2011-02-10 11:07 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/30ecf5c90a30 7014477: pt_BR corba resource bundle is missing in jdk7 build Reviewed-by: ohair ! make/common/Defs.gmk Changeset: c08dff674e53 Author: mfang Date: 2011-02-10 14:25 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/c08dff674e53 7017734: jdk7 message drop 1 translation integration Reviewed-by: ogino, yhuang ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties Changeset: e0f0b358cd2c Author: mfang Date: 2011-02-11 22:50 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/e0f0b358cd2c Merge Changeset: 563a8f8b5be3 Author: mfang Date: 2011-02-11 23:35 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/563a8f8b5be3 Merge Changeset: 49a96611c870 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/49a96611c870 Added tag jdk7-b130 for changeset 563a8f8b5be3 ! .hgtags Changeset: a9335b646c1c Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/a9335b646c1c 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 9d6dd2cdfcb9 Author: cl Date: 2011-02-23 15:48 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/9d6dd2cdfcb9 Merge Changeset: 1b1e75e8f476 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/1b1e75e8f476 Added tag jdk7-b131 for changeset 9d6dd2cdfcb9 ! .hgtags Changeset: 8ee094220abc Author: mcimadamore Date: 2011-03-01 15:03 +0000 URL: http://hg.openjdk.java.net/lambda/collections/corba/rev/8ee094220abc merge with jdk7-b131 From brian.goetz at oracle.com Thu Mar 10 15:45:05 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 10 Mar 2011 23:45:05 +0000 Subject: hg: lambda/collections/hotspot: 148 new changesets Message-ID: <20110310234944.8EB234704C@hg.openjdk.java.net> Changeset: 09d92cbb793b Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/09d92cbb793b Added tag jdk7-b124 for changeset 0a8e0d4345b3 ! .hgtags Changeset: f6a707dbaddb Author: trims Date: 2011-01-07 19:09 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/f6a707dbaddb Added tag hs20-b05 for changeset 0a8e0d4345b3 ! .hgtags Changeset: 9fc3ffb1e0b1 Author: trims Date: 2011-01-07 22:42 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/9fc3ffb1e0b1 7011125: Bump the HS20 build number to 06 Summary: Update the HS20 build number to 06 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 6da3527317ff Author: kevinw Date: 2010-12-17 12:14 +0000 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/6da3527317ff 7003487: clhsdbproc stacktrace fails on x64 Reviewed-by: phh ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java Changeset: 02895c6a2f82 Author: bobv Date: 2010-12-20 14:30 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/02895c6a2f82 7007769: VM crashes with SIGBUS writing PerfData if tmp space is full Summary: Fill perfdata file with zeros to verify available disk space Reviewed-by: coleenp, kamg ! src/os/linux/vm/perfMemory_linux.cpp Changeset: e58d06a8037e Author: dholmes Date: 2010-12-21 23:39 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/e58d06a8037e 7008444: Remove unnecessary include of stdint.h in java_md.c Summary: Remove unnecessary include of stdint.h in java_md.c Reviewed-by: brutisso, kvn ! src/os/posix/launcher/java_md.c Changeset: 1e637defdda6 Author: zgu Date: 2010-12-22 11:24 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/1e637defdda6 6961186: Better VM handling of unexpected exceptions from application native code Summary: Trap uncaught C++ exception on Windows and Solaris and generate hs_err report. Reviewed-by: coleenp, bobv, dholmes ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: c19157304e08 Author: zgu Date: 2010-12-22 11:52 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/c19157304e08 Merge ! src/os/windows/vm/os_windows.cpp Changeset: 3da13a976363 Author: coleenp Date: 2010-12-22 12:24 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/3da13a976363 Merge ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java Changeset: 07c62ff47437 Author: coleenp Date: 2010-12-22 16:52 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/07c62ff47437 Merge Changeset: d6cd0d55d0b5 Author: dcubed Date: 2010-12-23 07:58 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/d6cd0d55d0b5 6987812: 2/3 SAJDI: "gHotSpotVMTypes was not initialized properly in the remote process" Summary: Change ExportDirectoryTableImpl to return the 'Export RVA' field without modification. Read 'Base Of Data' field in optional header when PE32 format COFF file is read. Refine search for dbgeng.dll and dbghelp.dll. Other cleanups. Reviewed-by: swamyv, poonam ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/coff/COFFFileParser.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/coff/DumpExports.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/coff/TestParser.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java Changeset: e0c969b97f66 Author: zgu Date: 2010-12-27 09:30 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/e0c969b97f66 6975480: VS2010 says _STATIC_CPPLIB is deprecated, may need to change this usage Summary: Disabled the warning message during compiling. Reviewed-by: coleenp, dholmes ! make/windows/makefiles/compile.make Changeset: dbf8dcf069d1 Author: zgu Date: 2010-12-27 09:56 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/dbf8dcf069d1 Merge ! make/windows/makefiles/compile.make Changeset: 06e4b9c9db76 Author: coleenp Date: 2010-12-28 09:54 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/06e4b9c9db76 Merge Changeset: 7737fa7ec2b5 Author: twisti Date: 2010-12-14 12:44 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/7737fa7ec2b5 7006044: materialize cheap non-oop pointers on 64-bit SPARC Summary: After 6961690 we load non-oop pointers for the constant table which could easily be materialized in a few instructions. Reviewed-by: never, kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad Changeset: 781072b12368 Author: never Date: 2010-12-14 23:17 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/781072b12368 6765546: Wrong sscanf used to parse CompilerOracle command >= 32 characters could lead to crash Reviewed-by: kvn, iveresov ! src/share/vm/compiler/compilerOracle.cpp Changeset: 4042471b7419 Author: iveresov Date: 2010-12-16 01:46 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/4042471b7419 Merge Changeset: cccd1b172b85 Author: never Date: 2010-12-16 12:47 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/cccd1b172b85 6839888: Array overrun in vm adlc Reviewed-by: kvn, iveresov ! src/share/vm/adlc/dict2.cpp Changeset: c04052fd6ae1 Author: kvn Date: 2010-12-16 14:15 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/c04052fd6ae1 7006505: Use kstat info to identify SPARC processor Summary: read Solaris kstat data to get more precise CPU information Reviewed-by: iveresov, never, twisti, dholmes ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/vm.make ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/memory/universe.cpp Changeset: 7223744c2784 Author: never Date: 2010-12-17 15:55 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/7223744c2784 6579789: Internal error "c1_LinearScan.cpp:1429 Error: assert(false,"")" in debuggee with fastdebug VM Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp + test/compiler/6579789/Test6579789.java Changeset: 52d615436cef Author: never Date: 2010-12-18 06:40 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/52d615436cef Merge Changeset: 7d9caaedafce Author: twisti Date: 2010-12-18 01:15 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/7d9caaedafce 6990933: assert(sender_cb) failed: sanity in frame::sender_for_interpreter_frame Reviewed-by: never ! src/share/vm/code/nmethod.cpp Changeset: 1fb0500f550e Author: twisti Date: 2010-12-18 08:38 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/1fb0500f550e Merge Changeset: ef3c5db0b3ae Author: twisti Date: 2010-12-21 04:37 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/ef3c5db0b3ae 7008165: Garbage in ClassFormatError message Summary: When bootstrap_method_ref in BootstrapMethods attribute points to a wrong CP entry (non-MethodHandle), JVM throws ClassFormatError with a message, where method index and class file name is garbage. Reviewed-by: iveresov ! src/share/vm/classfile/classFileParser.cpp Changeset: a21ff35351ec Author: kvn Date: 2010-12-21 13:56 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/a21ff35351ec 7003130: assert(iterations start) failed: need enough space to divide up Summary: Codebuffer can overflow on test with large number of calls Reviewed-by: dholmes, collins ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp Changeset: 4537d449ba57 Author: bobv Date: 2011-01-07 15:57 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/4537d449ba57 Merge Changeset: b1a2afa37ec4 Author: phh Date: 2011-01-07 10:42 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/b1a2afa37ec4 7003271: Hotspot should track cumulative Java heap bytes allocated on a per-thread basis Summary: Track allocated bytes in Thread's, update on TLAB retirement and direct allocation in Eden and tenured, add JNI methods for ThreadMXBean. Reviewed-by: coleenp, kvn, dholmes, ysr ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/thread_solaris.inline.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp Changeset: 55d7d18ccff9 Author: dcubed Date: 2011-01-07 13:59 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/55d7d18ccff9 Merge Changeset: 84f36150fcc3 Author: dcubed Date: 2011-01-07 15:54 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/84f36150fcc3 Merge ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/os/solaris/vm/os_solaris.cpp Changeset: e24ab3fa6aaf Author: trims Date: 2011-01-07 22:56 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/e24ab3fa6aaf Merge ! make/jprt.properties Changeset: 4c851c931d00 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/4c851c931d00 Added tag jdk7-b125 for changeset e24ab3fa6aaf ! .hgtags Changeset: 102466e70deb Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/102466e70deb Added tag jdk7-b126 for changeset 4c851c931d00 ! .hgtags Changeset: 907c1aed0f8c Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/907c1aed0f8c Added tag jdk7-b127 for changeset 102466e70deb ! .hgtags Changeset: e4f8c88cf6f0 Author: trims Date: 2011-01-13 22:49 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/e4f8c88cf6f0 Added tag hs20-b06 for changeset e24ab3fa6aaf ! .hgtags Changeset: 76d6282dcfe5 Author: trims Date: 2011-01-13 22:53 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/76d6282dcfe5 7012348: Bump the HS20 build number to 07 Summary: Update the HS20 build number to 07 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 55f868e91c3b Author: iveresov Date: 2011-01-06 16:03 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/55f868e91c3b 7010618: C1: array length should be treated at int on 64bit during array allocation Summary: Sign-extend the length argument during array allocation Reviewed-by: never, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 0e52ef6e94d3 Author: twisti Date: 2011-01-07 03:58 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/0e52ef6e94d3 Merge Changeset: 4fc084dac61e Author: kvn Date: 2011-01-07 10:16 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/4fc084dac61e 7009756: volatile variables could be broken throw reflection API Summary: Use Atomic::load() and Atomic::store() to access a volatile long. Reviewed-by: iveresov, jrose, dholmes, never ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp ! src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/share/vm/prims/unsafe.cpp Changeset: 78e248949382 Author: kvn Date: 2011-01-07 11:53 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/78e248949382 6876037: CTW fails jdk7/hotspot/src/share/vm/opto/type.cpp:2055. assert(bits,"Use TypePtr for NULL") Summary: Add missing 0 value check in TypeRawPtr::add_offset(). Reviewed-by: never ! src/share/vm/opto/type.cpp Changeset: d810e9a3fc33 Author: twisti Date: 2011-01-10 00:56 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/d810e9a3fc33 7010180: JSR 292 InvokeDynamicPrintArgs fails with: assert(_adapter == NULL) failed: init'd to NULL Reviewed-by: never ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 70427f06ea47 Author: twisti Date: 2011-01-10 03:58 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/70427f06ea47 7010913: JSR 292 ciMethodHandle does not handle MethodHandleCompiler exceptions properly Reviewed-by: kvn, never ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/prims/methodHandleWalk.cpp Changeset: dd031b2226de Author: iveresov Date: 2011-01-10 18:46 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/dd031b2226de 4930919: race condition in MDO creation at back branch locations Summary: Reuse set_method_data_for_bcp() to setup mdp after MDO creation. Reviewed-by: kvn, never ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp Changeset: d4fca0a6abde Author: kvn Date: 2011-01-11 20:26 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/d4fca0a6abde 7011386: race in objArrayKlass::array_klass_impl Summary: Move _lower_dimension field initialization before _higher_dimension and add storestore barrier. Reviewed-by: dholmes, iveresov, never ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: bb8e3b66bde6 Author: twisti Date: 2011-01-13 07:20 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/bb8e3b66bde6 Merge ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il Changeset: c17b998c5926 Author: iveresov Date: 2011-01-12 18:33 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/c17b998c5926 7011627: C1: call_RT must support targets that don't fit in wdisp30 Summary: Make both compilers emit near and far calls when necessary. Reviewed-by: never, kvn, phh ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/sparc.ad Changeset: 5ae3e3b03224 Author: twisti Date: 2011-01-13 07:28 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/5ae3e3b03224 Merge ! src/cpu/sparc/vm/assembler_sparc.hpp Changeset: df307487d610 Author: dholmes Date: 2011-01-09 17:16 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/df307487d610 7010665: Misplaced membar in C1 implementation of Unsafe.get/putXXX Summary: Modify membars to match regular volatile variable handling Reviewed-by: iveresov, kvn, never ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: e31d8c656c5b Author: dcubed Date: 2011-01-10 09:23 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/e31d8c656c5b Merge ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 7246a374a9f2 Author: kamg Date: 2011-01-10 17:14 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/7246a374a9f2 6458402: 3 jvmti tests fail with CMS and +ExplicitGCInvokesConcurrent Summary: Make JvmtiGCMark safe to run non-safepoint and instrument CMS Reviewed-by: ysr, dcubed ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/jniHandles.cpp Changeset: db2b0f8c1cef Author: kamg Date: 2011-01-11 10:06 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/db2b0f8c1cef 6814943: getcpool001 catches more than one JvmtiThreadState problem Summary: Mark field volatile, use membars, and change access order to close race Reviewed-by: dcubed, dholmes ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 5577848f5923 Author: phh Date: 2011-01-11 17:33 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/5577848f5923 7011463: Sparc MacroAssembler::incr_allocated_bytes() needs a RegisterOrConstant argument Summary: Replaced incr_allocated_bytes() formals var_size_in_bytes and con_size_in_bytes with a single RegisterOrConstant formal. Reviewed-by: twisti, jcoomes ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp Changeset: 0ca32cc95d7b Author: phh Date: 2011-01-11 17:50 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/0ca32cc95d7b Merge Changeset: 8f8dfba37802 Author: kevinw Date: 2011-01-12 15:44 +0000 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/8f8dfba37802 6994753: Implement optional hook to a Java method at VM startup. Reviewed-by: mchung, acorn ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/thread.cpp Changeset: 34d64ad817f4 Author: coleenp Date: 2011-01-12 13:59 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/34d64ad817f4 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined Summary: Change get_temp_directory() back to /tmp and %TEMP% like it always was and where the tools expect it to be. Reviewed-by: phh, dcubed, kamg, alanb ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 856ecff79cf7 Author: dcubed Date: 2011-01-13 08:32 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/856ecff79cf7 Merge ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp Changeset: 4947ee68d19c Author: ysr Date: 2011-01-06 23:50 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/4947ee68d19c 7008136: CMS: assert((HeapWord*)nextChunk <= _limit) failed: sweep invariant Summary: The recorded _sweep_limit may not necessarily remain a block boundary as the old generation expands during a concurrent cycle. Terminal actions inside the sweep closure need to be aware of this as they cross over the limit. Reviewed-by: johnc, minqi ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp Changeset: 2250ee17e258 Author: tonyp Date: 2011-01-12 13:06 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/2250ee17e258 7007068: G1: refine the BOT during evac failure handling Summary: During evacuation failure handling we refine the BOT to reflect the location of all the objects in the regions we scan. The changeset includes some minor cleanup: a) non-product print_on() method on the G1 BOT class, b) added more complete BOT verification during heap / region verification, c) slight modification to the BOT set up for humongous regions to be more consistent with the BOT set up during evac failure handling, and d) removed a couple of unused methods. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: b158bed62ef5 Author: tonyp Date: 2011-01-12 16:34 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/b158bed62ef5 6994297: G1: do first-level slow-path allocations with a CAS Summary: First attempt to allocate out the current alloc region using a CAS instead of taking the Heap_lock (first level of G1's slow allocation path). Only if that fails and it's necessary to replace the current alloc region take the Heap_lock (that's the second level of G1's slow allocation path). Reviewed-by: johnc, brutisso, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 2e0b0c4671e4 Author: brutisso Date: 2011-01-13 04:43 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/2e0b0c4671e4 6941122: G1: UseLargePages does not work with G1 garbage collector Summary: Pass the value of UseLargePages instead of false as the "large" parameter when reserving the G1 heap. Reviewed-by: tonyp, johnc, phh ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: c91cc404ca46 Author: ysr Date: 2011-01-13 11:33 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/c91cc404ca46 7011940: iCMS: SIGSEGV in SweepClosure::do_already_free_chunk(FreeChunk*)+0x360 Summary: Revert a (relaxed version of the) bounds-check that was incorrectly removed in the fix for 7008136. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: ffd725ff6943 Author: johnc Date: 2011-01-13 17:19 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/ffd725ff6943 Merge ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 0915f9be781c Author: trims Date: 2011-01-13 22:54 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/0915f9be781c Merge Changeset: 75efcee5ac47 Author: minqi Date: 2010-10-07 13:49 -0700 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/75efcee5ac47 6966589: hs16-b08 causes java.lang.StackOverflowError Reviewed-by: mchung, dholmes, chrisphi ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp Changeset: 85c73c0edb06 Author: kvn Date: 2011-01-18 17:10 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/85c73c0edb06 7012965: Fix failed on sparc for 7009756: volatile variables could be broken throw reflection API Summary: Use LDX/STX on v9 and LDD/STD on v8 sparc for volatile long moves. Reviewed-by: never ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.il Changeset: b599a4c6c2df Author: iveresov Date: 2011-01-18 18:00 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/b599a4c6c2df 7012766: assert(false) failed: DEBUG MESSAGE in MacroAssembler::debug32 Summary: Interpreter expects to see methodOop in rbx on method entry, which needs to be restored after call to profile_method. Reviewed-by: kvn, never ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp Changeset: 8012aa3ccede Author: never Date: 2011-01-13 22:15 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/8012aa3ccede 4926272: methodOopDesc::method_from_bcp is unsafe Reviewed-by: coleenp, jrose, kvn, dcubed ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodBlocks.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/methodLiveness.cpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeStream.cpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/relocator.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/vframeArray.cpp Changeset: 17c778814856 Author: coleenp Date: 2011-01-14 13:47 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/17c778814856 6811367: Fix code in HeapDumper::dump_heap() to avoid buffer overrun Summary: Check buffer size before using and use dynamic buffer sizes for subsequent calls. Reviewed-by: kamg, dholmes ! src/share/vm/services/heapDumper.cpp Changeset: 633a44a9fc45 Author: dcubed Date: 2011-01-19 07:15 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/633a44a9fc45 Merge ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp Changeset: c1a0ede55d6f Author: dcubed Date: 2011-01-19 07:41 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/c1a0ede55d6f 7012493: 2/2 6849574/Test.java fails with Internal Error (src/share/vm/prims/jvmtiTagMap.cpp:3294) Summary: Refine assertion to work before VMThread has started. Reviewed-by: ysr, never, dholmes, acorn ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 2f33b03bd915 Author: never Date: 2011-01-19 08:16 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/2f33b03bd915 7013008: 2/3 assert(method == NULL || check_method(method, bcp)) failed: bcp must point into method Summary: The Relocator should pass a NULL methodOop when rewriting since its resource array can never contain breakpoints. Reviewed-by: dcubed, kvn, coleenp ! src/share/vm/runtime/relocator.hpp Changeset: 9afee0b9fc1d Author: kamg Date: 2011-01-19 13:51 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/9afee0b9fc1d 7012505: BreakpointWithFullGC.sh fails with Internal Error (src/share/vm/oops/methodOop.cpp:220) Summary: Rebuild breakpoint cache at gc_epilogue instead of during oops_do Reviewed-by: dcubed, ysr, coleenp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/runtime/jniHandles.cpp Changeset: 02b6913287da Author: dcubed Date: 2011-01-19 19:24 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/02b6913287da Merge Changeset: 7e37af9d69ef Author: tonyp Date: 2011-01-19 09:35 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/7e37af9d69ef 7011379: G1: overly long concurrent marking cycles Summary: This changeset introduces filtering of SATB buffers at the point when they are about to be enqueued. If this filtering clears enough entries on each buffer, the buffer can then be re-used and not enqueued. This cuts down the number of SATB buffers that need to be processed by the concurrent marking threads. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: 182e9624aa42 Author: johnc Date: 2011-01-19 13:01 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/182e9624aa42 7012642: G1: JumbleGC002 test aborts with segmentation violation due to uncaught stack overflow Summary: With recent G1 allocation path changes, the value of StackShadowPages in fast debug builds of the JVM, is no longer large enough to prevent the JVM C++ code from touching the stack guard pages. Increase the value of StackShadowPages to a suitable value. Reviewed-by: ysr, tonyp, coleenp ! src/cpu/x86/vm/globals_x86.hpp Changeset: cb913d743d09 Author: johnc Date: 2011-01-19 13:04 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/cb913d743d09 Merge Changeset: 0fa27f37d4d4 Author: tonyp Date: 2011-01-19 19:30 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/0fa27f37d4d4 6977804: G1: remove the zero-filling thread Summary: This changeset removes the zero-filling thread from G1 and collapses the two free region lists we had before (the "free" and "unclean" lists) into one. The new free list uses the new heap region sets / lists abstractions that we'll ultimately use it to keep track of all regions in the heap. A heap region set was also introduced for the humongous regions. Finally, this change increases the concurrency between the thread that completes freeing regions (after a cleanup pause) and the rest of the system (before we'd have to wait for said thread to complete before allocating a new region). The changest also includes a lot of refactoring and code simplification. Reviewed-by: jcoomes, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp + src/share/vm/gc_implementation/g1/heapRegionSet.cpp + src/share/vm/gc_implementation/g1/heapRegionSet.hpp + src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp + src/share/vm/gc_implementation/g1/heapRegionSets.cpp + src/share/vm/gc_implementation/g1/heapRegionSets.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 377371490991 Author: johnc Date: 2011-01-20 13:57 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/377371490991 Merge - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp Changeset: 5668ad215b80 Author: trims Date: 2011-01-20 17:53 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/5668ad215b80 Merge ! .hgtags Changeset: 98bf1c6bb73a Author: trims Date: 2011-01-20 18:24 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/98bf1c6bb73a Merge Changeset: 85330eaa15ee Author: iveresov Date: 2011-01-21 00:01 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/85330eaa15ee 7013812: C1: deopt blob too far from patching stub Summary: Use long jumps to get from patching stubs to deopt blob Reviewed-by: kvn, never ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp Changeset: d535bf4c1235 Author: trims Date: 2011-01-21 02:07 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/d535bf4c1235 Merge Changeset: 9a5762f44859 Author: trims Date: 2011-02-01 18:57 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/9a5762f44859 Merge ! .hgtags - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp Changeset: 6ecdca5709df Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/6ecdca5709df Added tag jdk7-b128 for changeset 9a5762f44859 ! .hgtags Changeset: 6aa467001334 Author: trims Date: 2011-01-25 14:57 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/6aa467001334 Added tag hs20-b07 for changeset d535bf4c1235 ! .hgtags Changeset: d19d8218a399 Author: trims Date: 2011-01-25 15:06 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/d19d8218a399 7014711: Fork HS20 to HS21 - renumber Major and build numbers of JVM Summary: Update the Major and Build numbers for HS21 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ccfcb502af3f Author: dholmes Date: 2011-01-25 00:14 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/ccfcb502af3f 6566340: Restore use of stillborn flag to signify a thread that was stopped before it started Summary: Restore use of stillborn flag Reviewed-by: acorn, alanb ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/thread.cpp Changeset: 515cc1a31fd1 Author: dcubed Date: 2011-01-26 21:26 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/515cc1a31fd1 Merge Changeset: bb2c2878f134 Author: twisti Date: 2011-01-20 08:25 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/bb2c2878f134 7011839: JSR 292 turn on escape analysis when using invokedynamic Summary: Currently escape analysis is turned off when EnableInvokeDynamic is true. Reviewed-by: jrose, kvn ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/runtime/arguments.cpp Changeset: a7367756024b Author: twisti Date: 2011-01-21 01:16 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/a7367756024b Merge ! src/share/vm/ci/bcEscapeAnalyzer.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp Changeset: 403dc4c1d7f5 Author: never Date: 2011-01-21 13:01 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/403dc4c1d7f5 6809483: hotspot:::method_entry are not correctly generated for "method()V" Reviewed-by: iveresov, twisti ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: aa4b04b68652 Author: never Date: 2011-01-21 13:03 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/aa4b04b68652 Merge ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: e4fee0bdaa85 Author: never Date: 2011-01-24 13:34 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/e4fee0bdaa85 7008809: should report the class in ArrayStoreExceptions from compiled code Reviewed-by: iveresov, twisti ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp Changeset: f966c66b5463 Author: iveresov Date: 2011-01-25 14:38 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/f966c66b5463 7014247: CTW fails when compile sun/misc/AtomicLongCSImpl (REMOVED from JDK7) Summary: Use lea to compute field address in AtomicLongCSImpl::attemptUpdate() intrinsic on x86. Reviewed-by: never, kvn ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: 635b068a7224 Author: twisti Date: 2011-01-27 08:47 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/635b068a7224 Merge ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp Changeset: 9846d99e16d3 Author: twisti Date: 2011-01-27 14:05 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/9846d99e16d3 Merge Changeset: a672e43650cc Author: tonyp Date: 2011-01-21 11:30 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/a672e43650cc 7013718: G1: small fixes for two assert/guarantee failures Summary: Two small fixes to deal with a guarantee failure (the marking thread should join the SuspendibleThreadSet before calling a method that does pause prediction work so that said method is never called during a pause) and an assert failure (an assert is too strong). Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: 97ba643ea3ed Author: tonyp Date: 2011-01-25 17:58 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/97ba643ea3ed 7014261: G1: RSet-related failures Summary: A race between the concurrent cleanup thread and the VM thread while it is processing the "expanded sparse table list" causes both threads to try to free the same sparse table entry and either causes one of the threads to fail or leaves the entry in an inconsistent state. The solution is purge all entries on the expanded list that correspond go regions that are being cleaned up. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: 234761c55641 Author: johnc Date: 2011-01-25 10:56 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/234761c55641 6608385: G1: need to support parallel reference processing Summary: Implement support for ParallelRefProcEnabled in the reference processing that takes place at the end of G1 concurrent marking. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 81668b1f4877 Author: johnc Date: 2011-01-26 09:57 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/81668b1f4877 Merge ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 27e4ea99855d Author: johnc Date: 2011-01-27 13:42 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/27e4ea99855d Merge ! src/share/vm/runtime/arguments.cpp Changeset: 3582bf76420e Author: coleenp Date: 2011-01-27 16:11 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/3582bf76420e 6990754: Use native memory and reference counting to implement SymbolTable Summary: move symbols from permgen into C heap and reference count them Reviewed-by: never, acorn, jmasa, stefank ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithKlass.java ! agent/src/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/PlaceholderEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/StringTable.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java - agent/src/share/classes/sun/jvm/hotspot/oops/SymbolKlass.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/types/Field.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp - src/share/vm/ci/ciSymbolKlass.cpp - src/share/vm/ci/ciSymbolKlass.hpp ! src/share/vm/ci/compilerInterface.hpp ! src/share/vm/classfile/classFileError.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/javaAssertions.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/resolutionErrors.cpp ! src/share/vm/classfile/resolutionErrors.hpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/compilerOracle.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/memory/classify.cpp ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/restore.cpp ! src/share/vm/memory/serialize.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/generateOopMap.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlassKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp + src/share/vm/oops/symbol.cpp + src/share/vm/oops/symbol.hpp - src/share/vm/oops/symbolKlass.cpp - src/share/vm/oops/symbolKlass.hpp - src/share/vm/oops/symbolOop.cpp - src/share/vm/oops/symbolOop.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fieldType.cpp ! src/share/vm/runtime/fieldType.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/interfaceSupport.cpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/rframe.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/hashtable.inline.hpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! src/share/vm/utilities/xmlstream.cpp ! src/share/vm/utilities/xmlstream.hpp Changeset: ae4b185f2ed1 Author: trims Date: 2011-02-03 23:26 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/ae4b185f2ed1 Merge ! .hgtags - agent/src/share/classes/sun/jvm/hotspot/oops/SymbolKlass.java - src/share/vm/ci/ciSymbolKlass.cpp - src/share/vm/ci/ciSymbolKlass.hpp - src/share/vm/oops/symbolKlass.cpp - src/share/vm/oops/symbolKlass.hpp - src/share/vm/oops/symbolOop.cpp - src/share/vm/oops/symbolOop.hpp Changeset: 55b9f498dbce Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/55b9f498dbce Added tag jdk7-b129 for changeset ae4b185f2ed1 ! .hgtags Changeset: 14c2f31280dd Author: trims Date: 2011-02-11 14:30 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/14c2f31280dd Added tag hs21-b01 for changeset ae4b185f2ed1 ! .hgtags Changeset: b7a938236e43 Author: tonyp Date: 2011-01-31 16:28 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/b7a938236e43 7014679: G1: deadlock during concurrent cleanup Summary: There's a potential deadlock between the concurrent cleanup thread and the GC workers that are trying to allocate and waiting for more free regions to be made available. Reviewed-by: iveresov, jcoomes ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: e49cfa28f585 Author: ysr Date: 2011-02-01 10:02 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/e49cfa28f585 6999988: CMS: Increased fragmentation leading to promotion failure after CR#6631166 got implemented Summary: Fix calculation of _desired, in free list statistics, which was missing an intended set of parentheses. Reviewed-by: poonam, jmasa ! src/share/vm/gc_implementation/shared/allocationStats.hpp Changeset: 986b2844f7a2 Author: brutisso Date: 2011-02-01 14:05 +0100 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/986b2844f7a2 6789220: CMS: intermittent timeout running nsk/regression/b4796926 Summary: The reference handler java thread and the GC could dead lock Reviewed-by: never, johnc, jcoomes ! src/share/vm/compiler/compileBroker.cpp Changeset: c33825b68624 Author: johnc Date: 2011-02-02 10:41 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/c33825b68624 6923430: G1: assert(res != 0,"This should have worked.") 7007446: G1: expand the heap with a single step, not one region at a time Summary: Changed G1CollectedHeap::expand() to expand the committed space by calling VirtualSpace::expand_by() once rather than for every region in the expansion amount. This allows the success or failure of the expansion to be determined before creating any heap regions. Introduced a develop flag G1ExitOnExpansionFailure (false by default) that, when true, will exit the VM if the expansion of the committed space fails. Finally G1CollectedHeap::expand() returns a status back to it's caller so that the caller knows whether to attempt the allocation. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 176d0be30214 Author: phh Date: 2011-02-03 16:06 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/176d0be30214 7016998: gcutil class LinearLeastSquareFit doesn't initialize some of its fields Summary: Initialize _sum_x_squared, _intercept and _slope in constructor. Reviewed-by: bobv, coleenp ! src/share/vm/gc_implementation/shared/gcUtil.cpp Changeset: c6bf3ca2bb31 Author: trims Date: 2011-02-04 16:29 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/c6bf3ca2bb31 Merge Changeset: d70fe6ab4436 Author: coleenp Date: 2011-02-01 11:23 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/d70fe6ab4436 6588413: Use -fvisibility=hidden for gcc compiles Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT to visibility=default, add for jio_snprintf and others since -fvisibility=hidden overrides --version-script definitions. Reviewed-by: kamg, never ! make/linux/makefiles/gcc.make ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/x86/vm/jni_x86.h ! src/cpu/zero/vm/jni_zero.h ! src/os/linux/vm/jvm_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: b92c45f2bc75 Author: bobv Date: 2011-02-02 11:35 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/b92c45f2bc75 7016023: Enable building ARM and PPC from src/closed repository Reviewed-by: dholmes, bdelsart ! make/Makefile + make/closed.make ! make/jprt.properties ! make/linux/Makefile ! make/linux/makefiles/adlc.make + make/linux/makefiles/arm.make ! make/linux/makefiles/buildtree.make + make/linux/makefiles/ppc.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make + make/linux/platform_arm + make/linux/platform_ppc ! src/os/linux/vm/osThread_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/linux/vm/thread_linux.inline.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Defs.hpp ! src/share/vm/c1/c1_FpuStackSim.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/icBuffer.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/vmreg.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/cppInterpreterGenerator.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/interpreterGenerator.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jni_md.h ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/icache.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/registerMap.hpp ! src/share/vm/runtime/relocator.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/stackValueCollection.cpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/threadLocalStorage.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/copy.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 9cd8a2c2d584 Author: bobv Date: 2011-02-02 11:54 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/9cd8a2c2d584 Merge ! src/os/linux/vm/os_linux.cpp Changeset: face83fc8882 Author: coleenp Date: 2011-02-02 18:38 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/face83fc8882 7012088: jump to 0 address because of lack of memory ordering in SignatureHandlerLibrary::add Summary: Write method signature handler under lock to prevent race with growable array resizing Reviewed-by: dsamersoff, dholmes ! src/share/vm/interpreter/interpreterRuntime.cpp Changeset: bf8517f4e4d0 Author: kamg Date: 2011-02-02 14:38 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/bf8517f4e4d0 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" Summary: Defer posting events from the compiler thread: use service thread Reviewed-by: coleenp, dholmes, never, dcubed - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java + agent/src/share/classes/sun/jvm/hotspot/runtime/ServiceThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Thread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp + src/share/vm/runtime/serviceThread.cpp + src/share/vm/runtime/serviceThread.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/services/lowMemoryDetector.hpp ! src/share/vm/services/management.cpp ! src/share/vm/utilities/macros.hpp Changeset: d28def44457d Author: coleenp Date: 2011-02-03 21:30 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/d28def44457d 7017009: Secondary out of c-heap memory error reporting out of memory Summary: Use os::malloc() to allocate buffer to read elf symbols and check for null Reviewed-by: zgu, phh, dsamersoff, dholmes, dcubed ! src/share/vm/utilities/elfSymbolTable.cpp Changeset: 5e139f767ddb Author: coleenp Date: 2011-02-03 20:30 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/5e139f767ddb Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java Changeset: e9f24eebafd4 Author: rottenha Date: 2011-02-07 08:40 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/e9f24eebafd4 Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java Changeset: d8a72fbc4be7 Author: kamg Date: 2011-02-08 17:20 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/d8a72fbc4be7 7003401: Implement VM error-reporting functionality on erroneous termination Summary: Add support for distribution-specific error reporting Reviewed-by: coleenp, phh, jcoomes, ohair ! make/Makefile + make/altsrc.make - make/closed.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/top.make ! make/solaris/makefiles/vm.make ! make/windows/create_obj_files.sh ! make/windows/makefiles/vm.make ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp + src/share/vm/utilities/errorReporter.cpp + src/share/vm/utilities/errorReporter.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/vmError.cpp Changeset: fb539912d338 Author: coleenp Date: 2011-02-07 14:36 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/fb539912d338 6472925: OutOfMemoryError fails to generate stack trace as it now ought Summary: Print an additional message for OOM during stack trace printing Reviewed-by: dholmes, phh, acorn, kamg, dcubed ! src/share/vm/runtime/thread.cpp Changeset: 5fb3ee258e76 Author: coleenp Date: 2011-02-08 19:50 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/5fb3ee258e76 Merge - make/closed.make Changeset: f36c9fe788b8 Author: mchung Date: 2011-02-08 09:11 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/f36c9fe788b8 7017673: Remove setting of the sun.jkernel.DownloadManager as a boot classloader hook Reviewed-by: alanb, dcubed, coleenp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/thread.cpp Changeset: 5197f3d713a1 Author: mchung Date: 2011-02-08 22:27 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/5197f3d713a1 Merge - make/closed.make ! src/share/vm/runtime/thread.cpp Changeset: 63d374c54045 Author: ctornqvi Date: 2011-02-09 11:08 +0100 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/63d374c54045 7014918: Improve core/minidump handling in Hotspot Summary: Added Minidump support on Windows, enabled large page core dumps when coredump_filter is present and writing out path/rlimit for core dumps. Reviewed-by: poonam, dsamersoff, sla, coleenp ! src/os/linux/vm/os_linux.cpp + src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: b83527d0482d Author: ctornqvi Date: 2011-02-10 12:55 +0100 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/b83527d0482d 7018366: hotspot/runtime_erro Fix for 7014918 does not build using MVC 2003 Summary: Looking at API_VERSION_NUMBER define to see what version of dbghelp.h/imagehlp.h is included to determine what MINIDUMP_TYPEs are defined in the header file Reviewed-by: acorn, brutisso, sla ! src/os/windows/vm/os_windows.cpp Changeset: e1523f7fd848 Author: rottenha Date: 2011-02-11 05:40 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/e1523f7fd848 Merge - make/closed.make Changeset: 2a9f9f2200fa Author: trims Date: 2011-02-11 15:31 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/2a9f9f2200fa Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java Changeset: 762bc029de50 Author: trims Date: 2011-02-11 15:32 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/762bc029de50 7019104: Bump the HS21 build number to 02 Summary: Update the HS21 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e9aa2ca89ad6 Author: kamg Date: 2011-02-16 16:58 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/e9aa2ca89ad6 7019718: make error reporting flags product instead of diagnostic Summary: see synopsis Reviewed-by: acorn, coleenp ! src/share/vm/runtime/globals.hpp Changeset: 0a2ecf4cc384 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/0a2ecf4cc384 Added tag jdk7-b130 for changeset e9aa2ca89ad6 ! .hgtags Changeset: cdef89d821bd Author: ohair Date: 2011-02-16 13:30 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/cdef89d821bd 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 0aa3b4908911 Author: cl Date: 2011-02-23 15:48 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/0aa3b4908911 Merge Changeset: 2015d9b41531 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/2015d9b41531 Added tag jdk7-b131 for changeset 0aa3b4908911 ! .hgtags Changeset: f3e07ceeaed9 Author: trims Date: 2011-02-25 11:42 -0800 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/f3e07ceeaed9 Added tag hs21-b02 for changeset e9aa2ca89ad6 ! .hgtags Changeset: 7dc5384467e0 Author: coleenp Date: 2011-02-12 10:28 -0500 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/7dc5384467e0 7022659: errorHandler doesn't compile without precompiled headers Summary: add proper includes in errorHandler.hpp Reviewed-by: phh, kamg ! src/share/vm/utilities/errorReporter.hpp Changeset: 57053c7bee2c Author: mcimadamore Date: 2011-03-01 15:05 +0000 URL: http://hg.openjdk.java.net/lambda/collections/hotspot/rev/57053c7bee2c merge with jdk7-b131 - agent/src/share/classes/sun/jvm/hotspot/oops/SymbolKlass.java - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java - src/share/vm/ci/ciSymbolKlass.cpp - src/share/vm/ci/ciSymbolKlass.hpp - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp - src/share/vm/oops/symbolKlass.cpp - src/share/vm/oops/symbolKlass.hpp - src/share/vm/oops/symbolOop.cpp - src/share/vm/oops/symbolOop.hpp From brian.goetz at oracle.com Thu Mar 10 15:49:51 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 10 Mar 2011 23:49:51 +0000 Subject: hg: lambda/collections/jaxp: 16 new changesets Message-ID: <20110310234951.B1F7D4704D@hg.openjdk.java.net> Changeset: 6c9bdee0cc3a Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/6c9bdee0cc3a Added tag jdk7-b124 for changeset 57ed1f3bec72 ! .hgtags Changeset: 116b935148bc Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/116b935148bc Added tag jdk7-b125 for changeset 6c9bdee0cc3a ! .hgtags Changeset: 63190d0ca619 Author: ohair Date: 2010-12-16 13:10 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/63190d0ca619 7007257: jaxp 1.4.5 jdk7 1st integration Reviewed-by: joehw ! jaxp.properties Changeset: ce7b69a2d927 Author: lana Date: 2010-12-22 22:57 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/ce7b69a2d927 Merge Changeset: 3a829f5ba9d2 Author: lana Date: 2011-01-04 16:28 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/3a829f5ba9d2 Merge Changeset: 64c84c62ec2a Author: lana Date: 2011-01-13 14:55 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/64c84c62ec2a Merge Changeset: 2fde639439c1 Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/2fde639439c1 Merge Changeset: c532d6dbc8d1 Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/c532d6dbc8d1 Added tag jdk7-b126 for changeset 2fde639439c1 ! .hgtags Changeset: a42c6132c746 Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/a42c6132c746 Added tag jdk7-b127 for changeset c532d6dbc8d1 ! .hgtags Changeset: f5b60c5a310f Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/f5b60c5a310f Added tag jdk7-b128 for changeset a42c6132c746 ! .hgtags Changeset: ab107c1bc4b9 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/ab107c1bc4b9 Added tag jdk7-b129 for changeset f5b60c5a310f ! .hgtags Changeset: f2ad604323c0 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/f2ad604323c0 Added tag jdk7-b130 for changeset ab107c1bc4b9 ! .hgtags Changeset: a57220f22751 Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/a57220f22751 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: eab6f27131e4 Author: cl Date: 2011-02-23 15:48 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/eab6f27131e4 Merge Changeset: abe04c59a556 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/abe04c59a556 Added tag jdk7-b131 for changeset eab6f27131e4 ! .hgtags Changeset: 01bddf4e7b40 Author: mcimadamore Date: 2011-03-01 15:04 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jaxp/rev/01bddf4e7b40 merge with jdk7-b131 From brian.goetz at oracle.com Thu Mar 10 15:49:59 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 10 Mar 2011 23:49:59 +0000 Subject: hg: lambda/collections/jaxws: 16 new changesets Message-ID: <20110310234959.37F1A4704E@hg.openjdk.java.net> Changeset: d72eea121c3b Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/d72eea121c3b Added tag jdk7-b124 for changeset 86f60e5b3975 ! .hgtags Changeset: e8fc02b4c889 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/e8fc02b4c889 Added tag jdk7-b125 for changeset d72eea121c3b ! .hgtags Changeset: aca101db2361 Author: ohair Date: 2010-12-16 13:14 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/aca101db2361 7006853: Integrate JAX-WS 2.2.2 RI into JDK 7 Reviewed-by: ramap ! jaxws.properties Changeset: 8ac759987b08 Author: lana Date: 2010-12-22 22:57 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/8ac759987b08 Merge Changeset: 466e89f7e5be Author: lana Date: 2011-01-04 16:37 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/466e89f7e5be Merge ! jaxws.properties Changeset: dba69d6345d9 Author: lana Date: 2011-01-13 14:55 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/dba69d6345d9 Merge Changeset: 6d772c5119d5 Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/6d772c5119d5 Merge Changeset: ef19f173578c Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/ef19f173578c Added tag jdk7-b126 for changeset 6d772c5119d5 ! .hgtags Changeset: 88d74afc5593 Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/88d74afc5593 Added tag jdk7-b127 for changeset ef19f173578c ! .hgtags Changeset: 0f7b39ad9024 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/0f7b39ad9024 Added tag jdk7-b128 for changeset 88d74afc5593 ! .hgtags Changeset: ba1fac1c2083 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/ba1fac1c2083 Added tag jdk7-b129 for changeset 0f7b39ad9024 ! .hgtags Changeset: a8ffd75ad5df Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/a8ffd75ad5df Added tag jdk7-b130 for changeset ba1fac1c2083 ! .hgtags Changeset: 9e3904866cab Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/9e3904866cab 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 438abc0356cd Author: cl Date: 2011-02-23 15:49 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/438abc0356cd Merge Changeset: 0e57c3272d37 Author: cl Date: 2011-02-24 15:15 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/0e57c3272d37 Added tag jdk7-b131 for changeset 438abc0356cd ! .hgtags Changeset: 3344673321b6 Author: mcimadamore Date: 2011-03-01 15:04 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jaxws/rev/3344673321b6 merge with jdk7-b131 From brian.goetz at oracle.com Thu Mar 10 16:34:17 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 11 Mar 2011 00:34:17 +0000 Subject: hg: lambda/collections/langtools: 78 new changesets Message-ID: <20110311003651.A71EE47051@hg.openjdk.java.net> Changeset: 0eaca1e0d9ae Author: mcimadamore Date: 2011-02-25 09:43 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/0eaca1e0d9ae Bug: javac shouldn't generate bridge for defender A bad check in TransTypes make javac generate bridge methods for defenders - which is causing problems to the weaver. ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java + test/tools/javac/defender/TestNoBridgeOnDefenders.java Changeset: 1b56e8c66272 Author: mcimadamore Date: 2011-02-25 18:07 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/1b56e8c66272 Disallow SAM conversion where target-type is an abstract class. This patch brings the compiler in line with what has been discussed by the lambda EG. Old semantics is still allowed (mostly for the purposes of running existing regression tests) using the hidden flag -XDabstractSAM. ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/defender/Pos01.java ! test/tools/javac/lambda/BadAccess.java ! test/tools/javac/lambda/BadAccess02.java ! test/tools/javac/lambda/BadBreakContinue.java ! test/tools/javac/lambda/BadReturn.java ! test/tools/javac/lambda/Defender01.java ! test/tools/javac/lambda/ExceptionTransparency01.java ! test/tools/javac/lambda/ExceptionTransparency02.java ! test/tools/javac/lambda/ExceptionTransparency03.java ! test/tools/javac/lambda/LambdaCapture01.java ! test/tools/javac/lambda/LambdaCapture02.java ! test/tools/javac/lambda/LambdaCapture03.java ! test/tools/javac/lambda/LambdaCapture04.java ! test/tools/javac/lambda/LambdaCapture05.java ! test/tools/javac/lambda/LambdaConv01.java ! test/tools/javac/lambda/LambdaConv03.java ! test/tools/javac/lambda/LambdaConv05.java ! test/tools/javac/lambda/LambdaConv06.java ! test/tools/javac/lambda/LambdaConv08.java ! test/tools/javac/lambda/LambdaConv09.java ! test/tools/javac/lambda/LambdaConv10.java ! test/tools/javac/lambda/LambdaConv13.java ! test/tools/javac/lambda/LambdaConversionTest.java ! test/tools/javac/lambda/LambdaExpr01.java ! test/tools/javac/lambda/LambdaExpr02.java ! test/tools/javac/lambda/LambdaExpr04.java ! test/tools/javac/lambda/LambdaExpr05.java ! test/tools/javac/lambda/LambdaExprNotVoid.java ! test/tools/javac/lambda/LambdaScope01.java ! test/tools/javac/lambda/LambdaScope03.java ! test/tools/javac/lambda/LocalBreakAndContinue.java ! test/tools/javac/lambda/MethodReference01.java ! test/tools/javac/lambda/MethodReference02.java ! test/tools/javac/lambda/MethodReference03.java ! test/tools/javac/lambda/MethodReference05.java ! test/tools/javac/lambda/MethodReference07.java ! test/tools/javac/lambda/MethodReference08.java ! test/tools/javac/lambda/MethodReference09.java ! test/tools/javac/lambda/MethodReference10.java ! test/tools/javac/lambda/MethodReference11.java ! test/tools/javac/lambda/MethodReference12.java ! test/tools/javac/lambda/MethodReference13.java ! test/tools/javac/lambda/MethodReference14.java ! test/tools/javac/lambda/MethodReference15.java ! test/tools/javac/lambda/MethodReference16.java ! test/tools/javac/lambda/MethodReference17.java ! test/tools/javac/lambda/MethodReference18.java ! test/tools/javac/lambda/MethodReference19.java ! test/tools/javac/lambda/MethodReference20.java ! test/tools/javac/lambda/NakedThis.java ! test/tools/javac/lambda/TargetType01.java ! test/tools/javac/lambda/TargetType03.java ! test/tools/javac/lambda/TargetType04.java ! test/tools/javac/lambda/TargetType05.java ! test/tools/javac/lambda/TargetType06.java ! test/tools/javac/lambda/TargetType07.java ! test/tools/javac/lambda/TargetType08.java ! test/tools/javac/lambda/TargetType10.java ! test/tools/javac/lambda/TargetType11.java ! test/tools/javac/lambda/TargetType12.java ! test/tools/javac/lambda/TargetType13.java ! test/tools/javac/lambda/TargetType14.java ! test/tools/javac/lambda/TargetType15.java ! test/tools/javac/lambda/TargetType16.java ! test/tools/javac/lambda/badMemberRefBytecode/TestBadMemberRefBytecode.java ! test/tools/javac/meth/InvokeDynTrans.java Changeset: 83157b68b615 Author: mcimadamore Date: 2011-02-25 19:43 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/83157b68b615 Disallow SAM conversion where target-type is an abstract class (take two). This patch fixes a problem in Types.java discovered by Neal. Regression tests have been updated in order to remove redundant -XDabstractSAM flags. ! src/share/classes/com/sun/tools/javac/code/Types.java ! test/tools/javac/defender/Pos01.java ! test/tools/javac/lambda/BadAccess.java ! test/tools/javac/lambda/BadAccess02.java ! test/tools/javac/lambda/BadBreakContinue.java ! test/tools/javac/lambda/BadLambdaFinder01.java ! test/tools/javac/lambda/BadLambdaPos.java ! test/tools/javac/lambda/BadOrder.java ! test/tools/javac/lambda/BadReturn.java ! test/tools/javac/lambda/BadTargetType.java ! test/tools/javac/lambda/Defender01.java ! test/tools/javac/lambda/DefiniteAssignment01.java ! test/tools/javac/lambda/ExceptionTransparency01.java ! test/tools/javac/lambda/ExceptionTransparency02.java ! test/tools/javac/lambda/ExceptionTransparency03.java ! test/tools/javac/lambda/LambdaCapture01.java ! test/tools/javac/lambda/LambdaCapture02.java ! test/tools/javac/lambda/LambdaCapture03.java ! test/tools/javac/lambda/LambdaCapture04.java ! test/tools/javac/lambda/LambdaCapture05.java ! test/tools/javac/lambda/LambdaConv01.java ! test/tools/javac/lambda/LambdaConv02.java ! test/tools/javac/lambda/LambdaConv03.java ! test/tools/javac/lambda/LambdaConv05.java ! test/tools/javac/lambda/LambdaConv06.java ! test/tools/javac/lambda/LambdaConv07.java ! test/tools/javac/lambda/LambdaConv08.java ! test/tools/javac/lambda/LambdaConv10.java ! test/tools/javac/lambda/LambdaConv11.java ! test/tools/javac/lambda/LambdaConv12.java ! test/tools/javac/lambda/LambdaConv13.java ! test/tools/javac/lambda/LambdaConv14.java ! test/tools/javac/lambda/LambdaExpr01.java ! test/tools/javac/lambda/LambdaExpr02.java ! test/tools/javac/lambda/LambdaExpr04.java ! test/tools/javac/lambda/LambdaExpr05.java ! test/tools/javac/lambda/LambdaExprNotVoid.java ! test/tools/javac/lambda/LambdaScope01.java ! test/tools/javac/lambda/LambdaScope02.java ! test/tools/javac/lambda/LambdaScope03.java ! test/tools/javac/lambda/LocalBreakAndContinue.java ! test/tools/javac/lambda/MethodReference01.java ! test/tools/javac/lambda/MethodReference02.java ! test/tools/javac/lambda/MethodReference03.java ! test/tools/javac/lambda/MethodReference04.java ! test/tools/javac/lambda/MethodReference05.java ! test/tools/javac/lambda/MethodReference06.java ! test/tools/javac/lambda/MethodReference07.java ! test/tools/javac/lambda/MethodReference08.java ! test/tools/javac/lambda/MethodReference09.java ! test/tools/javac/lambda/MethodReference10.java ! test/tools/javac/lambda/MethodReference11.java ! test/tools/javac/lambda/MethodReference12.java ! test/tools/javac/lambda/MethodReference13.java ! test/tools/javac/lambda/MethodReference20.java ! test/tools/javac/lambda/NakedThis.java ! test/tools/javac/lambda/TargetType01.java ! test/tools/javac/lambda/TargetType02.java ! test/tools/javac/lambda/TargetType03.java ! test/tools/javac/lambda/TargetType04.java ! test/tools/javac/lambda/TargetType05.java ! test/tools/javac/lambda/TargetType06.java ! test/tools/javac/lambda/TargetType07.java ! test/tools/javac/lambda/TargetType08.java ! test/tools/javac/lambda/TargetType10.java ! test/tools/javac/lambda/TargetType11.java ! test/tools/javac/lambda/TargetType12.java ! test/tools/javac/lambda/TargetType13.java ! test/tools/javac/lambda/TargetType14.java ! test/tools/javac/lambda/TargetType15.java ! test/tools/javac/lambda/TargetType16.java ! test/tools/javac/lambda/TargetType17.java ! test/tools/javac/lambda/badMemberRefBytecode/TestBadMemberRefBytecode.java ! test/tools/javac/meth/InvokeDynTrans.java Changeset: 4b0560c72b52 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/4b0560c72b52 Added tag jdk7-b124 for changeset 4868a36f6fd8 ! .hgtags Changeset: 62bdb6767734 Author: cl Date: 2011-01-13 16:44 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/62bdb6767734 Added tag jdk7-b125 for changeset 4b0560c72b52 ! .hgtags Changeset: a8d3eed8e247 Author: jjh Date: 2010-12-13 17:35 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/a8d3eed8e247 6999460: Glassfish build with JDK 6 / 7 is 5x-10x slower on Windows than on Linux Summary: Fixed JavacFileManager to not treat a non-existant pathname as a directory. Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java Changeset: 0141f508b98d Author: jjg Date: 2010-12-14 14:17 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/0141f508b98d 6999891: DefaultFileManager incorrect Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java + test/tools/javac/processing/filer/TestValidRelativeNames.java Changeset: cff0b8694633 Author: jjg Date: 2010-12-15 06:39 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/cff0b8694633 7006564: NPE in javac running test/tools/javac/nio/compileTest/CompileTest.java Reviewed-by: mcimadamore, alanb ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! test/tools/javac/nio/compileTest/CompileTest.java Changeset: 3131e664558d Author: ksrini Date: 2010-12-18 09:38 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/3131e664558d 6567415: Neverending loop in ClassReader Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java + test/tools/javac/6567415/T6567415.java Changeset: 7c33098600b2 Author: jjh Date: 2010-12-21 16:29 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/7c33098600b2 7008378: javac bootstrap launcher fails on cygwin when called via an absolute path Summary: Use cygpath if it is cygwin Reviewed-by: ksrini ! make/Makefile ! make/build.xml ! src/share/bin/launcher.sh-template Changeset: 8859e49909e6 Author: lana Date: 2010-12-22 23:15 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/8859e49909e6 Merge Changeset: dd38bab326a3 Author: jjh Date: 2010-12-23 10:08 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/dd38bab326a3 7008869: Debug printlns accidentally added to make/build.xml Summary: Delete bogus echo statements Reviewed-by: ksrini ! make/build.xml Changeset: e8719f95f2d0 Author: jjh Date: 2010-12-23 12:29 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/e8719f95f2d0 6982992: Tests CheckAttributedTree.java, JavacTreeScannerTest.java, and SourceTreeeScannerTest.java timeout Summary: Hoist some invariant code out of a loop Reviewed-by: ksrini ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/AbstractTreeScannerTest.java ! test/tools/javac/tree/TreePosTest.java Changeset: e63b1f8341ce Author: lana Date: 2011-01-04 17:10 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/e63b1f8341ce Merge ! make/Makefile ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! test/tools/javac/nio/compileTest/CompileTest.java Changeset: 15484cb7e5ae Author: mcimadamore Date: 2011-01-05 09:59 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/15484cb7e5ae 7010194: several langtools regression failures after JSR 292 changes (b123) Summary: Some regression tests rely on unsupported JSR 292 features Reviewed-by: jjg ! test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDyn.java - test/tools/javac/meth/InvokeDynTrans.java ! test/tools/javac/meth/XlintWarn.java Changeset: 20fec1b88bc1 Author: lana Date: 2011-01-13 15:05 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/20fec1b88bc1 Merge - test/tools/javac/meth/InvokeDyn.java - test/tools/javac/meth/InvokeDynTrans.java Changeset: 438a8ad60f7a Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/438a8ad60f7a Merge Changeset: 1e6094c33187 Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/1e6094c33187 Added tag jdk7-b126 for changeset 438a8ad60f7a ! .hgtags Changeset: d79e283c7d9b Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/d79e283c7d9b Added tag jdk7-b127 for changeset 1e6094c33187 ! .hgtags Changeset: d17f37522154 Author: jjg Date: 2011-01-10 14:57 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/d17f37522154 6992999: fully remove JSR 308 from langtools Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! test/tools/javac/diags/examples.not-yet.txt Changeset: 7c537f4298fb Author: jjg Date: 2011-01-10 15:08 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/7c537f4298fb 6396503: javac should not require assertions enabled Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java + src/share/classes/com/sun/tools/javac/util/Assert.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/UnsharedNameTable.java ! src/share/classes/javax/tools/ToolProvider.java Changeset: 17b271281525 Author: jjg Date: 2011-01-11 08:05 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/17b271281525 6993305: starting position of a method without modifiers and with type parameters is incorrect Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/tree/T6993305.java Changeset: d33d8c381aa1 Author: jjg Date: 2011-01-13 11:48 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/d33d8c381aa1 6430241: Hard to disable symbol file feature through API Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java + test/tools/javac/api/T6430241.java Changeset: a466f00c5cd2 Author: bpatel Date: 2011-01-13 21:28 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/a466f00c5cd2 7010528: javadoc performance regression Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java Changeset: 2d5aff89aaa3 Author: mcimadamore Date: 2011-01-14 09:45 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/2d5aff89aaa3 6992698: JSR 292: remove support for transient syntax in polymorphic signature calls Summary: special syntax to denote indy return type through type parameters should be removed (and cast shall be used instead) Reviewed-by: jjg, jrose ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/Names.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out ! test/tools/javac/meth/TestCP.java ! test/tools/javac/meth/XlintWarn.java Changeset: c8d312dd17bc Author: mcimadamore Date: 2011-01-14 09:45 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/c8d312dd17bc 7007432: Test generic types well-formedness Summary: add a new kind of check (well-formedness of generic type w.r.t. declared bounds) in the type-harness Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/types/GenericTypeWellFormednessTest.java ! test/tools/javac/types/TypeHarness.java Changeset: 712be35e40b5 Author: mcimadamore Date: 2011-01-14 09:46 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/712be35e40b5 6949040: java.dyn package must be compiled with -target 7 or better Summary: issue error (rather than warning) when @PolymorphicSignature is found and target < 7 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt Changeset: 7c7c1787fbbe Author: jjg Date: 2011-01-14 11:45 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/7c7c1787fbbe 6419926: JSR 199: FileObject.toUri() generates URI without schema (Solaris) Reviewed-by: mcimadamore + test/tools/javac/api/T6419926.java Changeset: 0a509c765657 Author: jjg Date: 2011-01-14 11:55 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/0a509c765657 6571165: Minor doc bugs in JavaCompiler.java Reviewed-by: mcimadamore ! src/share/classes/javax/tools/JavaCompiler.java Changeset: 19f9b6548c70 Author: ksrini Date: 2011-01-14 13:59 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/19f9b6548c70 7011272: langtools build.xml should provide a patch target Reviewed-by: jonathan, jjh ! make/build.xml Changeset: 5cf6c432ef2f Author: ksrini Date: 2011-01-18 08:37 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/5cf6c432ef2f 6982999: tools must support -target 7 bytecodes Reviewed-by: jjg, jrose ! src/share/classes/com/sun/tools/classfile/Attribute.java + src/share/classes/com/sun/tools/classfile/BootstrapMethods_attribute.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java Changeset: b6f95173e769 Author: lana Date: 2011-01-19 19:01 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/b6f95173e769 Merge Changeset: 19c900c703c6 Author: mcimadamore Date: 2011-01-24 15:44 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/19c900c703c6 6943278: spurious error message for inference and type-variable with erroneous bound Summary: type-inference should ignore erroneous bounds Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/6943278/T6943278.java + test/tools/javac/generics/inference/6943278/T6943278.out Changeset: ce6175cfe11e Author: mcimadamore Date: 2011-01-24 15:44 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/ce6175cfe11e 6968793: issues with diagnostics Summary: several diagnostic improvements Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6304921/T6304921.out ! test/tools/javac/6330920/T6330920.out ! test/tools/javac/6717241/T6717241a.out ! test/tools/javac/6717241/T6717241b.out ! test/tools/javac/6857948/T6857948.out ! test/tools/javac/6863465/T6863465c.out ! test/tools/javac/6863465/T6863465d.out ! test/tools/javac/T6247324.out ! test/tools/javac/TryWithResources/ResourceOutsideTry.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/CantResolve.java ! test/tools/javac/diags/examples/CantResolveArgsParams.java ! test/tools/javac/diags/examples/CantResolveLocation.java ! test/tools/javac/diags/examples/CantResolveLocationArgs.java ! test/tools/javac/diags/examples/CantResolveLocationArgsParams.java - test/tools/javac/diags/examples/EnumConstRequired.java ! test/tools/javac/diags/examples/ForeachNotApplicable.java ! test/tools/javac/diags/examples/KindnameClass.java ! test/tools/javac/diags/examples/KindnameMethod.java ! test/tools/javac/diags/examples/KindnameVariable.java + test/tools/javac/diags/examples/Location.java + test/tools/javac/diags/examples/Location1.java ! test/tools/javac/diags/examples/OperatorCantBeApplied.java + test/tools/javac/diags/examples/OperatorCantBeApplied1.java ! test/tools/javac/diags/examples/StaticImportOnlyClassesAndInterfaces/StaticImportOnlyClassesAndInterfaces.java ! test/tools/javac/failover/FailOver01.out ! test/tools/javac/failover/FailOver02.out ! test/tools/javac/failover/FailOver04.out ! test/tools/javac/generics/6711619/T6711619a.out ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/diamond/neg/Neg02.out ! test/tools/javac/generics/diamond/neg/Neg03.out ! test/tools/javac/generics/diamond/neg/Neg04.out ! test/tools/javac/generics/diamond/neg/Neg11.out ! test/tools/javac/generics/inference/6943278/T6943278.out ! test/tools/javac/generics/typevars/5060485/Compatibility.out ! test/tools/javac/generics/typevars/5060485/Compatibility02.out + test/tools/javac/generics/typevars/6968793/T6968793.java + test/tools/javac/generics/typevars/6968793/T6968793.out ! test/tools/javac/policy/test1/byfile.ABD.out ! test/tools/javac/policy/test1/bytodo.ABD.out ! test/tools/javac/policy/test1/simple.ABD.out Changeset: 02e6e7dd1a64 Author: mcimadamore Date: 2011-01-24 15:45 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/02e6e7dd1a64 6510286: Wording of javac error for inner classes Summary: 'inner classes cannot have static declarations' message needs to be reworked Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/InnerNamedConstant_2.out Changeset: 812c6251ea78 Author: mcimadamore Date: 2011-01-24 15:45 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/812c6251ea78 6569633: Varargs: parser error when varargs element type is an array Summary: explicit error message when old-style array syntax is mixed with varargs 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/VarargsAndOldArraySyntax.java + test/tools/javac/varargs/6569633/T6569633.java + test/tools/javac/varargs/6569633/T6569633.out Changeset: 57e3b9bc7fb8 Author: mcimadamore Date: 2011-01-24 15:45 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/57e3b9bc7fb8 7013865: varargs: javac crashes during overload resolution with generic varargs Summary: fixed regression with varargs overload resolution that leads javac to crash Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/varargs/T7013865.java Changeset: 2314f2b07ae7 Author: lana Date: 2011-01-24 13:25 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/2314f2b07ae7 Merge - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java - test/tools/javac/diags/examples/EnumConstRequired.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out Changeset: d7225b476a5d Author: lana Date: 2011-01-28 10:06 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/d7225b476a5d Merge - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java - test/tools/javac/diags/examples/EnumConstRequired.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out Changeset: 1383d1ee8b5d Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/1383d1ee8b5d Added tag jdk7-b128 for changeset d7225b476a5d ! .hgtags Changeset: 03e7fc380090 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/03e7fc380090 Added tag jdk7-b129 for changeset 1383d1ee8b5d ! .hgtags Changeset: 73ab0b128918 Author: jjg Date: 2011-01-24 16:17 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/73ab0b128918 6963934: JCCompilationUnit.getImports does not report all imports Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/tree/T6963934.java Changeset: 22a040cbf0e0 Author: jjg Date: 2011-01-24 16:34 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/22a040cbf0e0 6581775: Fix the white space problem in javac shell tests Reviewed-by: mcimadamore ! test/tools/javac/ClassPathTest/ClassPathTest.sh ! test/tools/javac/ExtDirs/ExtDirs.sh ! test/tools/javac/Paths/Help.sh ! test/tools/javac/javazip/Test.sh ! test/tools/javac/versions/check.sh Changeset: a8437c34fdc7 Author: jjg Date: 2011-01-24 16:38 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/a8437c34fdc7 6988106: javac report 'java.lang.IllegalMonitorStateException' Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java + src/share/classes/com/sun/tools/javac/file/ZipFileIndexCache.java ! test/tools/javac/T6725036.java Changeset: 7f8794f9cc14 Author: darcy Date: 2011-01-25 17:02 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/7f8794f9cc14 7013420: Project Coin: remove general expression support from try-with-resources statement Reviewed-by: mcimadamore, jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/TryWithResources/BadTwrSyntax.out ! test/tools/javac/TryWithResources/DuplicateResource.java + test/tools/javac/TryWithResources/ExplicitFinal.java ! test/tools/javac/TryWithResources/ImplicitFinal.java ! test/tools/javac/TryWithResources/ImplicitFinal.out ! test/tools/javac/TryWithResources/TwrFlow.java ! test/tools/javac/TryWithResources/TwrFlow.out - test/tools/javac/TryWithResources/TwrInference.java - test/tools/javac/TryWithResources/TwrIntersection.java - test/tools/javac/TryWithResources/TwrIntersection02.java - test/tools/javac/TryWithResources/TwrIntersection02.out ! test/tools/javac/TryWithResources/TwrMultiCatch.java ! test/tools/javac/TryWithResources/TwrOnNonResource.java ! test/tools/javac/TryWithResources/TwrOnNonResource.out + test/tools/javac/diags/examples/TryResourceTrailingSemi.java Changeset: df371fd16386 Author: jjg Date: 2011-01-26 11:20 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/df371fd16386 6554097: "final" confuses @SuppressWarnings Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/T6554097.java + test/tools/javac/T6554097.out Changeset: 3da26790ccb7 Author: jjg Date: 2011-01-26 13:45 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/3da26790ccb7 7013272: Automatically generate info about how compiler resource keys are used Reviewed-by: mcimadamore ! make/build.xml ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/ArgTypeCompilerFactory.java ! test/tools/javac/diags/Example.java + test/tools/javac/diags/MessageFile.java + test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java Changeset: 92ab09ed59fd Author: jjh Date: 2011-01-28 00:09 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/92ab09ed59fd 7015482: jtreg test tools/javac/diags/MessageInfo.java fails when test/ dir is not in langtools repo Summary: Don't fail if the needed file isn't present, if running under jtreg. Reviewed-by: jjg ! test/tools/javac/diags/MessageInfo.java Changeset: 2088e674f0e0 Author: mcimadamore Date: 2011-01-28 12:01 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/2088e674f0e0 6910550: javac 1.5.0_17 fails with incorrect error message Summary: multiple clashing members declared in same class should be added to the class' scope in order to avoid downstream spurious diagnostics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/6910550/T6910550a.java + test/tools/javac/generics/6910550/T6910550a.out + test/tools/javac/generics/6910550/T6910550b.java + test/tools/javac/generics/6910550/T6910550b.out + test/tools/javac/generics/6910550/T6910550c.java + test/tools/javac/generics/6910550/T6910550c.out + test/tools/javac/generics/6910550/T6910550d.java + test/tools/javac/generics/6910550/T6910550d.out + test/tools/javac/generics/6910550/T6910550e.java + test/tools/javac/generics/6910550/T6910550e.out Changeset: 5a43b245aed1 Author: mcimadamore Date: 2011-01-28 12:03 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/5a43b245aed1 6313164: javac generates code that fails byte code verification for the varargs feature Summary: method applicability check should fail if formal varargs element type is not accessible Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/InaccessibleVarargsType/InaccessibleVarargsType.java + test/tools/javac/diags/examples/InaccessibleVarargsType/p1/A.java + test/tools/javac/diags/examples/InaccessibleVarargsType/p1/B.java ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712d.out + test/tools/javac/varargs/6313164/T6313164.java + test/tools/javac/varargs/6313164/T6313164.out + test/tools/javac/varargs/6313164/p1/A.java + test/tools/javac/varargs/6313164/p1/B.java + test/tools/javac/varargs/6313164/p1/C.java Changeset: 17bafae67e9d Author: mcimadamore Date: 2011-01-28 12:06 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/17bafae67e9d 6838943: inference: javac is not handling type-variable substitution properly Summary: free type-variables are being replaced with type-variables bound to forall type leading to unsoundness Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/inference/6838943/T6838943.java + test/tools/javac/generics/inference/6838943/T6838943.out Changeset: babf86a1ac92 Author: alanb Date: 2011-01-28 09:25 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/babf86a1ac92 7006126: (fs) Updates to file system API (1/2011) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! test/tools/javac/nio/compileTest/CompileTest.java Changeset: df3394337b04 Author: alanb Date: 2011-01-28 12:36 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/df3394337b04 Merge Changeset: 7a75a1803c7a Author: darcy Date: 2011-01-28 16:54 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/7a75a1803c7a 7015530: Reiterate API specializations in javax.lang.model.elment subinterfaces Reviewed-by: jjg ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java ! src/share/classes/javax/lang/model/element/PackageElement.java ! src/share/classes/javax/lang/model/element/TypeElement.java ! src/share/classes/javax/lang/model/element/TypeParameterElement.java ! src/share/classes/javax/lang/model/element/VariableElement.java Changeset: 2ab47c4cd618 Author: darcy Date: 2011-01-31 19:06 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/2ab47c4cd618 7014734: Project Coin: Allow optional trailing semicolon to terminate resources list in try-with-resources 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/TryWithResources/BadTwrSyntax.java ! test/tools/javac/TryWithResources/BadTwrSyntax.out - test/tools/javac/diags/examples/TryResourceTrailingSemi.java Changeset: cad51b6eb7a6 Author: darcy Date: 2011-02-01 10:11 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/cad51b6eb7a6 6961571: Update visitors to support ARM's ElementKind.RESOURCE_VARIABLE Reviewed-by: jjg + src/share/classes/javax/lang/model/type/DisjunctiveType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.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/ElementKindVisitor6.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor7.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/SimpleAnnotationValueVisitor7.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/SimpleTypeVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java ! src/share/classes/javax/lang/model/util/Types.java ! test/tools/javac/processing/model/element/TestResourceVariable.java Changeset: 899f7c3d9426 Author: mcimadamore Date: 2011-02-03 09:35 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/899f7c3d9426 6594914: @SuppressWarnings("deprecation") does not not work for the type of a variable Summary: Lint warnings generated during MemberEnter might ignore @SuppressWarnings annotations Reviewed-by: jjg + src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/warnings/6594914/DeprecatedClass.java + test/tools/javac/warnings/6594914/T6594914a.java + test/tools/javac/warnings/6594914/T6594914a.out + test/tools/javac/warnings/6594914/T6594914b.java + test/tools/javac/warnings/6594914/T6594914b.out Changeset: 875262e89b52 Author: mcimadamore Date: 2011-02-03 09:36 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/875262e89b52 5017953: spurious cascaded diagnostics when name not found Summary: when an operator is applied to one or more erroneous operands, spurious diagnostics are generated Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/5017953/T5017953.java + test/tools/javac/5017953/T5017953.out ! test/tools/javac/6491592/T6491592.out Changeset: 03cf47d4de15 Author: mcimadamore Date: 2011-02-03 09:37 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/03cf47d4de15 6969184: poor error recovery after symbol not found Summary: generic type-well formedness check should ignore erroneous symbols Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/6969184/T6969184.java + test/tools/javac/generics/6969184/T6969184.out Changeset: afe226180744 Author: mcimadamore Date: 2011-02-03 09:38 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/afe226180744 7014715: javac returns different error code for certain failure(s) Summary: javac silently crashes when emitting certain kinds of resolution diagnostics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/AnonStaticMember_2.java + test/tools/javac/AnonStaticMember_2.out ! test/tools/javac/InterfaceInInner.java + test/tools/javac/InterfaceInInner.out ! test/tools/javac/QualifiedNew.java + test/tools/javac/QualifiedNew.out ! test/tools/javac/T6247324.out ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/inference/6943278/T6943278.out Changeset: 9e6a09375d37 Author: lana Date: 2011-02-04 17:30 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/9e6a09375d37 Merge Changeset: 3aa269645199 Author: mcimadamore Date: 2011-02-07 18:09 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/3aa269645199 7017414: before the move of JSR 292 to package java.lang.invoke, javac must recognize the new package Summary: added support for future 292 package (support for old location 'java.dyn' will be removed in followup changeset) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/util/Names.java Changeset: 96d4226bdd60 Author: mcimadamore Date: 2011-02-07 18:10 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/96d4226bdd60 7007615: java_util/generics/phase2/NameClashTest02 fails since jdk7/pit/b123. Summary: override clash algorithm is not implemented correctly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/NameClashSameErasureNoHide.java ! test/tools/javac/diags/examples/NameClashSameErasureNoOverride.java + test/tools/javac/diags/examples/NameClashSameErasureNoOverride1.java ! test/tools/javac/generics/5009937/T5009937.out ! test/tools/javac/generics/6182950/T6182950b.out ! test/tools/javac/generics/6476118/T6476118a.out ! test/tools/javac/generics/6476118/T6476118b.out ! test/tools/javac/generics/6476118/T6476118c.java ! test/tools/javac/generics/6476118/T6476118c.out ! test/tools/javac/generics/6985719/T6985719e.out ! test/tools/javac/generics/6985719/T6985719f.out ! test/tools/javac/generics/6985719/T6985719g.out ! test/tools/javac/generics/6985719/T6985719h.out + test/tools/javac/generics/7007615/T7007615.java + test/tools/javac/generics/7007615/T7007615.out + test/tools/javac/generics/7007615/acc1/AccessibilityCheck01.java + test/tools/javac/generics/7007615/acc1/p1/C.java + test/tools/javac/generics/7007615/acc1/p1/D.java + test/tools/javac/generics/7007615/acc1/p2/E.java + test/tools/javac/generics/7007615/acc2/AccessibilityCheck02.java + test/tools/javac/generics/7007615/acc2/AccessibilityCheck02.out + test/tools/javac/generics/7007615/acc2/p1/C.java + test/tools/javac/generics/7007615/acc2/p1/D.java + test/tools/javac/generics/7007615/acc2/p2/E.java ! test/tools/javac/scope/HashCollisionTest.java ! test/tools/javac/scope/StarImportTest.java Changeset: 56b77a38618c Author: jjg Date: 2011-02-07 11:42 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/56b77a38618c 7017675: typo in JavacParser for allowUnderscoresInLiterals Reviewed-by: dlsmith Contributed-by: peter.b.kessler at oracle.com ! src/share/classes/com/sun/tools/javac/parser/Scanner.java Changeset: 2cbaa43eb075 Author: lana Date: 2011-02-14 16:31 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/2cbaa43eb075 Merge - test/tools/javac/TryWithResources/TwrInference.java - test/tools/javac/TryWithResources/TwrIntersection.java - test/tools/javac/TryWithResources/TwrIntersection02.java - test/tools/javac/TryWithResources/TwrIntersection02.out Changeset: a21c7f194d31 Author: mfang Date: 2011-02-10 16:51 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/a21c7f194d31 7017734: jdk7 message drop 1 translation integration Reviewed-by: ogino, yhuang ! src/share/classes/com/sun/tools/apt/resources/apt_ja.properties ! src/share/classes/com/sun/tools/apt/resources/apt_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties Changeset: 4cdea0752a48 Author: mfang Date: 2011-02-11 22:58 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/4cdea0752a48 Merge Changeset: 26071d11c613 Author: mfang Date: 2011-02-11 23:49 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/26071d11c613 Merge Changeset: 7a98db8cbfce Author: ohair Date: 2011-02-15 12:34 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/7a98db8cbfce Merge Changeset: 6cdb76cf4d1a Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/6cdb76cf4d1a Added tag jdk7-b130 for changeset 7a98db8cbfce ! .hgtags Changeset: 22ea7d483794 Author: ohair Date: 2011-02-16 13:30 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/22ea7d483794 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 67221b8643b4 Author: cl Date: 2011-02-23 15:49 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/67221b8643b4 Merge Changeset: 80bbd1da4a72 Author: cl Date: 2011-02-24 15:16 -0800 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/80bbd1da4a72 Added tag jdk7-b131 for changeset 67221b8643b4 ! .hgtags Changeset: 3240fef7f13e Author: mcimadamore Date: 2011-03-01 15:02 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/3240fef7f13e merge with jdk7-b131 ! make/build.xml ! src/share/bin/launcher.sh-template ! src/share/classes/com/sun/runtime/ProxyHelper.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/Names.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! src/share/classes/javax/lang/model/util/Types.java - test/tools/javac/TryWithResources/TwrInference.java - test/tools/javac/TryWithResources/TwrIntersection.java - test/tools/javac/TryWithResources/TwrIntersection02.java - test/tools/javac/TryWithResources/TwrIntersection02.out ! test/tools/javac/diags/examples.not-yet.txt - test/tools/javac/diags/examples/EnumConstRequired.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/diamond/neg/Neg02.out ! test/tools/javac/generics/diamond/neg/Neg03.out ! test/tools/javac/generics/diamond/neg/Neg04.out ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712d.out + test/tools/javac/generics/inference/6838943/T6838943.out ! test/tools/javac/generics/typevars/5060485/Compatibility.out ! test/tools/javac/generics/typevars/5060485/Compatibility02.out ! test/tools/javac/lambda/BadLambdaPos.out - test/tools/javac/meth/InvokeDyn.java - test/tools/javac/meth/InvokeDynTrans.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out ! test/tools/javac/transparency/Neg03.out ! test/tools/javac/types/TypeHarness.java + test/tools/javac/varargs/6313164/T6313164.out Changeset: 5aeda537bf98 Author: mcimadamore Date: 2011-03-01 17:48 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/5aeda537bf98 Fix: wrong subtyping implementation for disjunctive types. Wrong subtyping between disjunctive types caused errors in method resolution. ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/lambda/DisjunctiveTypeTest.java Changeset: c80ead80fcfd Author: mcimadamore Date: 2011-03-07 11:50 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/c80ead80fcfd Fixed SAM conversion for corner case involving abstract classes implementing ''target'' abstract method. This is just for completeness, given that abstract classes support in SAM conversion has been dropped. ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/LambdaConv15.java Changeset: 1623ce0ec047 Author: mcimadamore Date: 2011-03-07 13:54 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/1623ce0ec047 Types.findSAM throws NPE when target type of SAM conversion is an interface inheriting non-overriding members. ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/BadConv03.java + test/tools/javac/lambda/BadConv03.out Changeset: c3dc67484a46 Author: briangoetz Date: 2011-03-10 18:42 -0500 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/c3dc67484a46 Merge - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java - test/tools/javac/TryWithResources/TwrInference.java - test/tools/javac/TryWithResources/TwrIntersection.java - test/tools/javac/TryWithResources/TwrIntersection02.java - test/tools/javac/TryWithResources/TwrIntersection02.out - test/tools/javac/diags/examples/EnumConstRequired.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDyn.java - test/tools/javac/meth/InvokeDynTrans.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out From brian.goetz at oracle.com Thu Mar 10 15:50:36 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 10 Mar 2011 23:50:36 +0000 Subject: hg: lambda/collections/jdk: 267 new changesets Message-ID: <20110311003403.4616547050@hg.openjdk.java.net> Changeset: 0a56bdd709d0 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/0a56bdd709d0 Added tag jdk7-b124 for changeset 1c72adc9d5f3 ! .hgtags Changeset: 3972926bc8f1 Author: cl Date: 2011-01-13 16:44 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/3972926bc8f1 Added tag jdk7-b125 for changeset 0a56bdd709d0 ! .hgtags Changeset: 4d6f9aaa2600 Author: flar Date: 2010-12-14 13:25 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/4d6f9aaa2600 6766342: Improve performance of Ductus rasterizer Reviewed-by: jgodinez, prr ! make/sun/awt/make.depend ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/loops/CompositeType.java ! src/share/classes/sun/java2d/loops/MaskFill.java ! src/share/classes/sun/java2d/pipe/AAShapePipe.java ! src/share/classes/sun/java2d/pipe/AlphaColorPipe.java ! src/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/native/sun/java2d/loops/DrawParallelogram.c ! src/share/native/sun/java2d/loops/FillParallelogram.c ! src/share/native/sun/java2d/loops/MaskFill.c + src/share/native/sun/java2d/loops/ParallelogramUtils.h ! src/solaris/native/sun/java2d/loops/vis_IntArgbPre_Mask.c ! src/solaris/native/sun/java2d/loops/vis_SrcMaskFill.c + test/java/awt/Graphics2D/RenderClipTest/6766342.tests + test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java Changeset: 9d0eebb55003 Author: bae Date: 2010-12-15 19:47 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/9d0eebb55003 6782574: AffineTransformOp.filter(BufferedImage, BufferedImage) fails with InternalError Reviewed-by: igor, prr ! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java ! src/share/native/sun/awt/image/awt_parseImage.c + test/java/awt/image/IncorrectSampleMaskTest.java Changeset: 6a219e5ccfd7 Author: bae Date: 2010-12-17 13:18 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/6a219e5ccfd7 7006948: FindBugs warning in IndexColorModel class Reviewed-by: igor, prr ! src/share/classes/java/awt/image/IndexColorModel.java Changeset: 33a0f66771d5 Author: jgodinez Date: 2010-12-17 09:39 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/33a0f66771d5 6635462: D3D: REGRESSION: XOR rendering is extremly slow Reviewed-by: igor, prr ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java Changeset: 0125062d65b6 Author: bae Date: 2010-12-20 10:38 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/0125062d65b6 6736178: java.awt.image.SampleModel constructor unexpectedly throws IllegalArgumentException Reviewed-by: jgodinez, prr ! src/share/classes/java/awt/image/SampleModel.java Changeset: b0f9760f3103 Author: prr Date: 2010-12-22 13:32 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/b0f9760f3103 7007299: FileFontStrike appears not to be threadsafe? Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FileFontStrike.java Changeset: 1513ccf103a9 Author: prr Date: 2010-12-22 13:49 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/1513ccf103a9 6996867: Garbage rendering of LCD text with SRC composite mode Reviewed-by: igor, jgodinez ! src/share/classes/sun/java2d/SurfaceData.java + test/java/awt/Graphics2D/DrawString/LCDTextSrcEa.java Changeset: 78d0a8d449fd Author: bae Date: 2010-12-23 14:27 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/78d0a8d449fd 7002627: JNI Critical Arrays should be released with the original (unmodified) pointer Reviewed-by: jgodinez, prr ! src/share/native/sun/java2d/pipe/BufferedMaskBlit.c Changeset: cb3c0ffb27bb Author: lana Date: 2010-12-23 00:03 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/cb3c0ffb27bb Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - test/java/dyn/JavaDocExamples.java Changeset: 155d91257957 Author: lana Date: 2010-12-23 08:47 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/155d91257957 Merge Changeset: 7fff69f28bf4 Author: jgodinez Date: 2010-12-23 10:38 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/7fff69f28bf4 6913300: Missing serialVersionUID in javax.print.attribute.standard.DialogTypeSelection Reviewed-by: igor, prr ! src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java Changeset: b22c74e20a1b Author: jgodinez Date: 2010-12-23 11:01 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/b22c74e20a1b 6949749: regression cases need to be updated by removing "System.exit(0)" Reviewed-by: igor, prr ! test/java/awt/PrintJob/Text/StringWidth.java Changeset: 417acb7e8fa1 Author: prr Date: 2010-12-23 15:28 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/417acb7e8fa1 6891551: Font rasterisation uses more heap than needed for some strikes. Reviewed-by: jgodinez ! src/share/classes/sun/font/FileFontStrike.java Changeset: 4e47e55dd717 Author: prr Date: 2010-12-23 21:58 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/4e47e55dd717 6927458: font system should cache transient strikes with weak references. Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/Font2D.java Changeset: 99c540ac926c Author: bae Date: 2010-12-24 14:05 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/99c540ac926c 6983028: java/awt/FontClass/FontPrivilege.java Reviewed-by: prr ! test/java/awt/FontClass/FontPrivilege.java Changeset: 14033e1600ac Author: prr Date: 2010-12-24 09:31 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/14033e1600ac 6997210: Solaris 11 has no development support for DGA: Cannot build JDK Reviewed-by: bae, ohair ! make/sun/Makefile Changeset: 70bfa0af3969 Author: bae Date: 2010-12-30 11:33 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/70bfa0af3969 7003434: test/closed/java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java fails with ClassCastExc Reviewed-by: jgodinez, prr ! src/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java Changeset: 9320dcfb5398 Author: lana Date: 2011-01-05 11:21 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/9320dcfb5398 Merge - make/common/internal/BinaryPlugs.gmk ! make/sun/Makefile ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! src/share/classes/java/awt/image/IndexColorModel.java ! src/share/classes/java/awt/image/SampleModel.java ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/native/sun/java2d/loops/DrawParallelogram.c ! src/share/native/sun/java2d/loops/FillParallelogram.c ! src/windows/classes/sun/awt/windows/WComponentPeer.java Changeset: 3db5ac2b4c62 Author: andrew Date: 2010-12-14 13:51 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/3db5ac2b4c62 6444769: java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html fails Summary: Remove unneeded test Reviewed-by: anthony - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java Changeset: b9706aff91a3 Author: lana Date: 2010-12-15 11:49 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/b9706aff91a3 Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: 4a0970a420d5 Author: anthony Date: 2010-12-16 21:48 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/4a0970a420d5 6993803: Request to update SplashScreen specification 6984255: Request for java.awt.SplashScreen spec update: mention possibility of having custom "-splash" option 6992416: [Spec clarification request] Is color deviation for splash screen image allowed? 6992833: [Spec clarification request] point (0,0) in SplashScreen.createGraphics() 6993071: java.awt.SplashScreen should mention that no unnecessary distortions to the image are allowed 6993113: [Spec clarification request] getSplashScreen(): null or HeadlessException? 6996439: [Spec clarification request] Is any delay with splashscreen appearance allowed? Summary: Update SplashScreen specification Reviewed-by: art ! src/share/classes/java/awt/SplashScreen.java Changeset: 8dbb797793b0 Author: anthony Date: 2010-12-22 17:37 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/8dbb797793b0 6998323: Unexpected color change after invoking SplashScreen.update() Summary: Fix the blendRGB() function Reviewed-by: art, dcherepanov ! src/share/native/sun/awt/splashscreen/splashscreen_gfx_impl.h Changeset: 15c45fdd572c Author: lana Date: 2010-12-23 10:20 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/15c45fdd572c Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java Changeset: 6e4d9f4466f6 Author: dcherepanov Date: 2010-12-27 18:37 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/6e4d9f4466f6 4887645: Remove "awt.threadgroup" system property Reviewed-by: art, anthony ! src/share/classes/sun/awt/SunToolkit.java Changeset: a0a4f73b3d1d Author: dcherepanov Date: 2010-12-27 18:42 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/a0a4f73b3d1d 6957765: Test Bug - javax/swing/SwingWorker/6480289/bug6480289.java failed on 1.7.0b94 but passed on previous Reviewed-by: art, alexp - test/javax/swing/SwingWorker/6480289/bug6480289.java Changeset: 33d4e0de0424 Author: dcherepanov Date: 2010-12-27 18:43 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/33d4e0de0424 6866808: nsk/stress/jck12a/jck12a014 crashes with SIGSEGV at [libjvm.so+0xc5b10] Reviewed-by: art ! src/solaris/native/sun/xawt/XToolkit.c Changeset: c90a0da7649e Author: dcherepanov Date: 2010-12-27 18:45 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/c90a0da7649e 6921598: PrinterDialog hidden behind other frames Reviewed-by: art ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Dialog.h Changeset: 39e9d5613145 Author: dav Date: 2010-12-28 17:13 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/39e9d5613145 6999766: Changes to correct c/c++ language issues for use of parfait Reviewed-by: uta, amenkov ! src/windows/native/sun/windows/Devices.h ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_Debug.cpp ! src/windows/native/sun/windows/awt_Debug.h ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_TextArea.h ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: 8b05f9b91765 Author: dav Date: 2010-12-29 15:13 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/8b05f9b91765 7008106: com/sun/awt/Translucency/WindowOpacity.java test fails just against jdk7 b122 Reviewed-by: dcherepanov ! test/com/sun/awt/Translucency/WindowOpacity.java Changeset: 78364959fc73 Author: dav Date: 2010-12-29 17:36 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/78364959fc73 6963357: After clicking the "Load" button,the case FileDialogUserFilterTest.html crashes in jdk7 b98. Reviewed-by: dcherepanov ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c Changeset: aa03f76d0e80 Author: lana Date: 2011-01-05 15:54 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/aa03f76d0e80 Merge - make/common/internal/BinaryPlugs.gmk ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/sun/awt/SunToolkit.java ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: bde32b5becf1 Author: lana Date: 2011-01-06 18:01 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/bde32b5becf1 Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java Changeset: ec02d02d3409 Author: okutsu Date: 2010-12-15 11:38 +0900 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/ec02d02d3409 6990037: font warnings in the build, missing fonts Reviewed-by: peytoia ! make/sun/awt/Makefile ! src/share/classes/sun/awt/FontConfiguration.java Changeset: cd7b5fb40005 Author: okutsu Date: 2010-12-17 16:56 +0900 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/cd7b5fb40005 7007583: (tz) Windows-only: update tzmappings for KB2443685 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: 7c7e4a0330bc Author: okutsu Date: 2010-12-17 17:13 +0900 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/7c7e4a0330bc 6644493: [Fmt-Da] SimpleDateFormat parsing RFC822 time offset is slow Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java ! test/java/text/Format/DateFormat/ISO8601ZoneTest.java Changeset: f710204034fd Author: okutsu Date: 2010-12-17 18:06 +0900 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/f710204034fd 6983207: API: MessageFormat quote handling discrepancy Reviewed-by: peytoia ! src/share/classes/java/text/MessageFormat.java Changeset: 89d065844fb6 Author: okutsu Date: 2010-12-21 10:58 +0900 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/89d065844fb6 6943959: NumericShaper API doc doesn't describe ARABIC/EASTERN_ARABIC precedence Reviewed-by: peytoia ! src/share/classes/java/awt/font/NumericShaper.java Changeset: 8da79c7d137e Author: okutsu Date: 2010-12-21 11:20 +0900 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/8da79c7d137e 7007905: javazic produces wrong line numbers Reviewed-by: peytoia ! make/tools/src/build/tools/javazic/Zoneinfo.java Changeset: 55d9205735e1 Author: naoto Date: 2010-12-21 16:14 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/55d9205735e1 4940539: Constructor of java.util.Locale should handle ISO 639-2 Language Codes Reviewed-by: okutsu ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleTest.java Changeset: 403a88eeac15 Author: lana Date: 2010-12-22 16:57 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/403a88eeac15 Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java Changeset: c8b383fd8adf Author: rupashka Date: 2010-12-23 17:39 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/c8b383fd8adf 6973773: JCK manual case JSliderTests.html#JSlider fails in jdk7 b100 Reviewed-by: alexp ! src/share/classes/javax/swing/JSlider.java Changeset: 69b2e5838eee Author: rupashka Date: 2010-12-23 18:25 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/69b2e5838eee 7007708: TEST: javax/swing/JScrollBar/6542335/bug6542335.java failes agaisnt jdk7 on solaris/linux Reviewed-by: alexp ! test/javax/swing/JScrollBar/6542335/bug6542335.java Changeset: 94e0438c74c3 Author: okutsu Date: 2010-12-27 14:13 +0900 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/94e0438c74c3 7003643: [Fmt-Me] MessageFormat.toPattern produces wrong quoted string and subformat modifiers 7008195: [Fmt-Me] Improve MessageFormat.applyPattern performance Reviewed-by: naoto, peytoia ! src/share/classes/java/text/MessageFormat.java + test/java/text/Format/MessageFormat/Bug7003643.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.sh ! test/java/util/PluggableLocale/NumberFormatProviderTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.sh ! test/java/util/PluggableLocale/fooprovider.jar ! test/java/util/PluggableLocale/providersrc/DateFormatProviderImpl.java + test/java/util/PluggableLocale/providersrc/FooDateFormat.java + test/java/util/PluggableLocale/providersrc/FooNumberFormat.java ! test/java/util/PluggableLocale/providersrc/Makefile ! test/java/util/PluggableLocale/providersrc/NumberFormatProviderImpl.java Changeset: c06d4327c0f2 Author: rupashka Date: 2010-12-27 15:28 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/c06d4327c0f2 6959584: closed/javax/swing/JFileChooser/4847375/bug4847375.java : compilation failed Reviewed-by: alexp + test/javax/swing/JFileChooser/4847375/bug4847375.java Changeset: 72f1247e9ff5 Author: rupashka Date: 2010-12-27 17:41 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/72f1247e9ff5 6532833: PIT: Metal LAF - The right side border is not shown for the Spinner after the removing the buttons Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicSpinnerUI.java + test/javax/swing/JSpinner/6532833/bug6532833.java Changeset: 2c3c88a389b0 Author: amenkov Date: 2010-12-28 16:37 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/2c3c88a389b0 6842956: Assertion error in javax_sound on 64-bit RHEL 5.3 with 32-bit JDK Reviewed-by: bae ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_MidiIn.c Changeset: ac1e3f99a69e Author: amenkov Date: 2010-12-29 16:26 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/ac1e3f99a69e 7006997: A typo in MidiSystem.getTransmitter() implementation code Reviewed-by: dav ! src/share/classes/javax/sound/midi/MidiSystem.java Changeset: be27227ff554 Author: amenkov Date: 2010-12-30 14:57 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/be27227ff554 6989702: sound native code compiler warnings Reviewed-by: bae ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_MidiUtils.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCM.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCMUtils.h ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c Changeset: 349b67ae3e08 Author: lana Date: 2011-01-04 23:41 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/349b67ae3e08 Merge - make/common/internal/BinaryPlugs.gmk ! make/sun/awt/Makefile ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/javax/sound/midi/MidiSystem.java Changeset: fff6fd437f4a Author: lana Date: 2011-01-06 18:03 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/fff6fd437f4a Merge Changeset: 6d3fb387da8e Author: ksrini Date: 2010-12-14 07:42 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/6d3fb387da8e 6990106: FindBugs scan - Malicious code vulnerability Warnings in com.sun.java.util.jar.pack.* Reviewed-by: mduigou, briangoetz ! src/share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/Coding.java ! src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Histogram.java ! src/share/classes/com/sun/java/util/jar/pack/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/PopulationCoding.java ! src/share/classes/com/sun/java/util/jar/pack/PropMap.java ! src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java ! src/share/classes/com/sun/java/util/jar/pack/Utils.java ! src/share/classes/java/util/jar/Pack200.java Changeset: 68cc30a3a1fd Author: ksrini Date: 2010-12-14 08:13 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/68cc30a3a1fd 7006704: (pack200) add missing file for 6990106 Reviewed-by: mduigou, briangoetz + src/share/classes/com/sun/java/util/jar/pack/FixedList.java Changeset: a72e7147816f Author: lancea Date: 2010-12-14 16:08 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/a72e7147816f 7006454: Typo in javadocs typo for Statement.executeBatch @since Reviewed-by: alanb ! src/share/classes/java/sql/Statement.java Changeset: 0ef137ae6f3b Author: alanb Date: 2010-12-15 09:15 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/0ef137ae6f3b 6927816: Demo crash in heaptracker with Non-Sun JDK due to possible violation of JNI spec Reviewed-by: ohair, alanb Contributed-by: spoole at uk.ibm.com ! src/share/demo/jvmti/heapTracker/heapTracker.c Changeset: e6ed7c95d94f Author: xuelei Date: 2010-12-15 22:42 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/e6ed7c95d94f 7006265: Javadoc warnings Reviewed-by: weijun ! src/share/classes/javax/net/ssl/X509ExtendedTrustManager.java Changeset: e67a399dd4ad Author: sundar Date: 2010-12-16 20:52 +0530 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/e67a399dd4ad 6980447: Rhino JavaScript engine code in jdk-7 has to updated with the latest code from Rhino 1.7R3. Summary: Updating Rhino javascript engine with version 1.7R3. Issue 6427783 (E4X support is missing from Sun's Mozilla JavaScript implementation) is also fixed as a side-effect. Reviewed-by: alanb, jjh ! src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java ! src/share/classes/com/sun/script/javascript/RhinoScriptEngineFactory.java ! src/share/classes/com/sun/script/javascript/RhinoTopLevel.java ! src/share/classes/com/sun/tools/script/shell/init.js - test/javax/script/E4XErrorTest.java ! test/javax/script/VersionTest.java Changeset: 1f0f0737f04e Author: weijun Date: 2010-12-17 11:03 +0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/1f0f0737f04e 6975866: api/org_ietf/jgss/GSSContext/index.html#wrapUnwrapIOTest started to fail since jdk7 b102 Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/CipherHelper.java ! src/share/classes/sun/security/jgss/krb5/MessageToken_v2.java ! src/share/classes/sun/security/jgss/krb5/MicToken_v2.java ! src/share/classes/sun/security/jgss/krb5/WrapToken.java ! src/share/classes/sun/security/jgss/krb5/WrapToken_v2.java ! test/sun/security/krb5/auto/BasicKrb5Test.java ! test/sun/security/krb5/auto/Context.java - test/sun/security/krb5/auto/basic.sh Changeset: ae84db37130a Author: ksrini Date: 2010-12-18 09:10 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/ae84db37130a 7007157: (pack200) stripping attributes causes a NPE Reviewed-by: jrose, mduigou, dholmes ! src/share/classes/com/sun/java/util/jar/pack/ClassReader.java + test/tools/pack200/T7007157.java Changeset: 449dfb061fde Author: smarks Date: 2010-12-20 13:47 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/449dfb061fde 6880112: Project Coin: Port JDK core library code to use diamond operator Reviewed-by: darcy, lancea, alanb, briangoetz, mduigou, mchung ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ! src/share/classes/com/sun/java/util/jar/pack/Package.java ! src/share/classes/java/io/DeleteOnExitHook.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/ObjectInputStream.java ! src/share/classes/java/io/ObjectOutputStream.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/lang/ApplicationShutdownHooks.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/CharacterName.java ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/StringCoding.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/Throwable.java ! src/share/classes/java/lang/management/ManagementFactory.java ! src/share/classes/java/lang/management/PlatformComponent.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Proxy.java ! src/share/classes/java/lang/reflect/ReflectAccess.java ! src/share/classes/java/sql/DriverManager.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/EnumMap.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/HashSet.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/JumboEnumSet.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/ListResourceBundle.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/RegularEnumSet.java ! src/share/classes/java/util/ServiceLoader.java ! src/share/classes/java/util/TimSort.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/java/util/logging/FileHandler.java ! src/share/classes/java/util/logging/Level.java ! src/share/classes/java/util/logging/LogManager.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/java/util/logging/Logger.java ! src/share/classes/java/util/logging/Logging.java ! src/share/classes/java/util/prefs/AbstractPreferences.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/sun/io/Converters.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! src/solaris/classes/java/lang/ProcessEnvironment.java ! src/solaris/classes/java/util/prefs/FileSystemPreferences.java ! src/windows/classes/java/lang/ProcessEnvironment.java ! test/java/io/Serializable/NPEProvoker/NPEProvoker.java ! test/java/lang/instrument/ilib/Inject.java ! test/java/lang/instrument/ilib/InjectBytecodes.java ! test/java/lang/reflect/Generics/TestPlainArrayNotGeneric.java ! test/java/util/Random/DistinctSeeds.java ! test/java/util/logging/ClassLoaderLeakTest.java Changeset: d2a0e795c1c2 Author: weijun Date: 2010-12-21 17:35 +0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/d2a0e795c1c2 6996367: improve HandshakeHash Reviewed-by: xuelei ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java Changeset: d36ad8686f6d Author: kevinw Date: 2010-12-21 11:32 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/d36ad8686f6d 6968933: Clip loop() deadlock in DirectAudioDevice$DirectClip.run Reviewed-by: amenkov ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java Changeset: 9deace8396f9 Author: ptisnovs Date: 2010-12-22 14:37 +0100 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/9deace8396f9 6560348: PIT : java/awt/xembed/server/RunTestXEmbed.java fails Summary: Testcase correction. Reviewed-by: anthony ! test/java/awt/xembed/server/TestXEmbedServer.java Changeset: 0d826185a92e Author: xuelei Date: 2010-12-22 06:28 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/0d826185a92e 6996365: Evaluate the priorities of cipher suites Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/CipherSuite.java Changeset: d4c2d2d72cfc Author: valeriep Date: 2010-12-22 18:30 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/d4c2d2d72cfc 6581254: pkcs11 provider fails to parse configuration file contains windows short path Summary: Modified configuration parsing code to support "~". Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/Config.java + test/sun/security/pkcs11/Provider/ConfigShortPath.java + test/sun/security/pkcs11/Provider/csp.cfg Changeset: 6acd81baf2c7 Author: lana Date: 2010-12-22 23:12 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/6acd81baf2c7 Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/util/ListResourceBundle.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java Changeset: 5beec82bf20d Author: ksrini Date: 2010-12-23 13:51 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/5beec82bf20d 7002386: (launcher) fix XshowSettings Reviewed-by: darcy, mchung, naoto ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java ! test/tools/launcher/Settings.java Changeset: 3c4afaacd345 Author: dcubed Date: 2010-12-23 23:10 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/3c4afaacd345 7005984: 3/3 Incorrect values of S0C and S0CMX appear with -gcnewcapacity in jstat Summary: Swap S0C and S0CMX column values. Reviewed-by: ohair, dholmes, poonam ! src/share/classes/sun/tools/jstat/resources/jstat_options ! test/sun/tools/jstat/gcNewCapacityOutput1.awk Changeset: adff75ebdc00 Author: valeriep Date: 2010-12-22 19:19 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/adff75ebdc00 6924489: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_OPERATION_NOT_INITIALIZED Summary: Reset cipher state to un-initialized wherever necessary. Reviewed-by: weijun ! src/share/classes/sun/security/pkcs11/P11Cipher.java Changeset: 3254c3ae63fe Author: valeriep Date: 2010-12-27 11:39 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/3254c3ae63fe Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java Changeset: 6f2d19ef67b1 Author: alanb Date: 2011-01-04 17:49 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/6f2d19ef67b1 7010192: InetAddress.isReachable hits ShouldNotReachHere with hs20-b04 (win) Reviewed-by: chegar ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c Changeset: 4379c762ec50 Author: sherman Date: 2011-01-04 14:17 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/4379c762ec50 7009618: regression test failed caused by the fix for 7003462 Summary: avoid caching the "ended" Inflater in ZipFile class Reviewed-by: alanb ! src/share/classes/java/util/zip/Inflater.java ! src/share/classes/java/util/zip/ZipFile.java + test/java/util/zip/ZipFile/FinalizeZipFile.java Changeset: 58aa8eadae5f Author: lana Date: 2011-01-04 17:05 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/58aa8eadae5f Merge - make/common/internal/BinaryPlugs.gmk ! src/share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/Coding.java ! src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Histogram.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.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/PopulationCoding.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/ListResourceBundle.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/sun/io/Converters.java ! src/share/classes/sun/tools/jstat/resources/jstat_options ! src/share/classes/sun/util/logging/PlatformLogger.java ! test/sun/security/krb5/auto/Context.java Changeset: d56c111ec6dc Author: jjg Date: 2011-01-06 14:32 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/d56c111ec6dc 7010537: javah no longer depends on javadoc Reviewed-by: ohair ! make/common/shared/Defs-java.gmk Changeset: c4ec4f80f44e Author: lana Date: 2011-01-06 18:05 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/c4ec4f80f44e Merge - test/javax/script/E4XErrorTest.java - test/sun/security/krb5/auto/basic.sh Changeset: 1513e13fae08 Author: lana Date: 2011-01-13 15:03 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/1513e13fae08 Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/security/krb5/auto/basic.sh Changeset: 8361ef97a0f9 Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/8361ef97a0f9 Merge Changeset: 29e09de1d0b4 Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/29e09de1d0b4 Added tag jdk7-b126 for changeset 8361ef97a0f9 ! .hgtags Changeset: 66c86ca4079a Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/66c86ca4079a Added tag jdk7-b127 for changeset 29e09de1d0b4 ! .hgtags Changeset: 63f5c7704faa Author: prr Date: 2011-01-12 15:58 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/63f5c7704faa 6958221: java.awt.Font.getFamily() leads to JVM crash on Linux on JDK7 for "custom" fonts Reviewed-by: igor, jgodinez ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/headless/mapfile-vers ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11FontManager.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/native/sun/awt/fontpath.c + test/java/awt/FontClass/X11FontPathCrashTest.java Changeset: 5aae8b3162d0 Author: prr Date: 2011-01-13 10:36 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/5aae8b3162d0 7001056: JDK 7 fails on to build on Solaris 10 update 9 - updated Xrender header files Reviewed-by: igor, jgodinez ! make/sun/xawt/Makefile ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 76b8fa7fd229 Author: prr Date: 2011-01-13 12:08 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/76b8fa7fd229 7012269: mapfile for headless awt needs getFontPathNative defined Reviewed-by: igor ! make/sun/headless/mapfile-vers Changeset: 9f3f38c150b5 Author: prr Date: 2011-01-13 14:11 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/9f3f38c150b5 6917884: NPE in sun.font.FcFontConfiguration.getPlatformFontNames Reviewed-by: igor, jgodinez ! src/solaris/classes/sun/font/FontConfigManager.java Changeset: 987aeabbfda3 Author: prr Date: 2011-01-14 11:05 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/987aeabbfda3 6951086: Excessive Local References in sun.font.SunLayoutEngine.nativeLayout Reviewed-by: igor, jgodinez ! src/share/native/sun/font/FontInstanceAdapter.cpp Changeset: 646c3cf1ba37 Author: prr Date: 2011-01-14 11:43 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/646c3cf1ba37 6989370: Windows platform fonts may be incorrectly marked as ineligible for the native rasteriser Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/SunFontManager.java ! src/windows/classes/sun/awt/Win32FontManager.java Changeset: 5cb6bb816a34 Author: prr Date: 2011-01-14 12:10 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/5cb6bb816a34 6925760: Scaled graphics can cause overlapped LCD mode strings on Windows for pixel size > 48 Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FileFontStrike.java + test/java/awt/FontClass/LCDScale.java Changeset: 8b33567d68b0 Author: jgodinez Date: 2011-01-14 14:25 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/8b33567d68b0 6939417: ArrayIndexOutOfBoundsException in Win 7 on selected printers Reviewed-by: igor, prr ! src/windows/classes/sun/print/Win32PrintService.java ! test/javax/print/DialogMargins.java Changeset: c2fcb5530ba5 Author: prr Date: 2011-01-14 15:07 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/c2fcb5530ba5 6930980: Disable TrueType hinting for fonts known not to hint well Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/NullFontScaler.java Changeset: 0bec5d506120 Author: dlila Date: 2011-01-19 09:44 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/0bec5d506120 4724552: CubicCurve2D.contains(Rectangle2D) returns true when only partially contained. Summary: Now using subdivision code in sun.awt.geom.Curve. Reviewed-by: flar ! src/share/classes/java/awt/geom/CubicCurve2D.java Changeset: c8a10bfd2fcb Author: dlila Date: 2011-01-19 11:31 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/c8a10bfd2fcb 4493128: CubicCurve2D intersects method fails Summary: Now using subdivision code in sun.awt.geom.Curve. Reviewed-by: flar ! src/share/classes/java/awt/geom/CubicCurve2D.java Changeset: 00cc1c09c6dd Author: prr Date: 2011-01-19 09:22 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/00cc1c09c6dd 6951501: EUDC character is not displayed on Swing Reviewed-by: igor, jgodinez ! src/windows/classes/sun/awt/Win32FontManager.java ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp Changeset: e58e9e32399a Author: prr Date: 2011-01-19 17:02 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/e58e9e32399a 6983037: closed/java/awt/font/FontNames/Type1Fonts.java failed due to missed font Reviewed-by: igor ! src/share/classes/sun/font/SunFontManager.java ! src/solaris/classes/sun/awt/X11FontManager.java Changeset: fe1b5c15afab Author: prr Date: 2011-01-19 17:07 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/fe1b5c15afab 7013109: windows application manifest problems 6820955: Update application manifests with new Windows 7 dpiAware section Reviewed-by: ohair, art ! make/common/Defs-windows.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! src/windows/resource/java.manifest Changeset: aa1825b1b69d Author: lana Date: 2011-01-19 19:35 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/aa1825b1b69d Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/security/krb5/auto/basic.sh Changeset: 0044e8e16a30 Author: prr Date: 2011-01-20 10:45 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/0044e8e16a30 6980204: closed/java/awt/font/LogicalFonts/MappingTest.java fails Reviewed-by: jgodinez ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java Changeset: b1c41e0321a2 Author: prr Date: 2011-01-20 13:56 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/b1c41e0321a2 7013646: remove obsolete fontconfig files for linux and solaris Reviewed-by: igor, jgodinez ! make/sun/awt/Makefile - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java ! src/solaris/classes/sun/font/FcFontConfiguration.java Changeset: b8f08482aca1 Author: prr Date: 2011-01-21 07:59 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/b8f08482aca1 6892493: potential memory leaks in 2D font code indentified by parfait. Reviewed-by: bae, igor ! src/solaris/native/sun/awt/fontpath.c Changeset: c17e5a95aba7 Author: prr Date: 2011-01-21 08:04 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/c17e5a95aba7 6892138: Windows GDI platform font lookup apis affect start-up for small UI apps Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/SunFontManager.java ! src/windows/classes/sun/awt/Win32FontManager.java + test/java/awt/font/FontNames/LocaleFamilyNames.java Changeset: ade796b84e71 Author: bae Date: 2011-01-24 15:14 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/ade796b84e71 7002766: Java2d: Changes to correct c/c++ language issues for use of parfait Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/image/jpeg/jmorecfg.h ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: 63a2e8e00a7b Author: bae Date: 2011-01-24 15:37 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/63a2e8e00a7b 6999620: [parfait] potential buffer overruns in 2d and awt Reviewed-by: jgodinez, prr ! src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 74d020ed7f5b Author: lana Date: 2011-01-24 13:18 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/74d020ed7f5b Merge - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties Changeset: 5d4723944cbd Author: dcherepanov Date: 2011-01-20 14:27 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/5d4723944cbd 7011446: ./windows/classes/sun/awt/windows/WToolkit.java needs to avoid spurious wakeup Reviewed-by: anthony ! src/windows/classes/sun/awt/windows/WToolkit.java Changeset: 1bb32dc775c8 Author: dcherepanov Date: 2011-01-20 14:28 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/1bb32dc775c8 7011443: ./share/classes/sun/awt/SunToolkit.java needs to avoid spurious wakeup Reviewed-by: anthony ! src/share/classes/sun/awt/SunToolkit.java Changeset: 4cd8718d4548 Author: dcherepanov Date: 2011-01-20 14:29 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/4cd8718d4548 7011442: AppletClassLoader.java needs to avoid spurious wakeup Reviewed-by: anthony ! src/share/classes/sun/applet/AppletClassLoader.java Changeset: 4c9a9871830f Author: lana Date: 2011-01-20 10:49 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/4c9a9871830f Merge - test/javax/script/E4XErrorTest.java - test/sun/security/krb5/auto/basic.sh Changeset: f6b73a9b3895 Author: lana Date: 2011-01-24 13:20 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/f6b73a9b3895 Merge Changeset: 63972a313ca4 Author: rupashka Date: 2011-01-11 12:51 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/63972a313ca4 6589952: Swing: dead links in API documentation Reviewed-by: alexp ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/SizeSequence.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/event/InternalFrameAdapter.java ! src/share/classes/javax/swing/event/InternalFrameListener.java ! src/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html ! src/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/ParagraphView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java Changeset: 2a966dd275fc Author: rupashka Date: 2011-01-13 20:12 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/2a966dd275fc 6990651: Regression: NPE when refreshing applet since 6u22-b01 Reviewed-by: peterz ! src/share/classes/javax/swing/text/html/parser/ParserDelegator.java + test/javax/swing/JLabel/7004134/bug7004134.java + test/javax/swing/text/html/parser/Parser/6990651/bug6990651.java Changeset: 5787add5b679 Author: rupashka Date: 2011-01-17 19:14 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/5787add5b679 6342301: Bad interaction between setting the ui and file filters in JFileChooser Reviewed-by: alexp ! src/share/classes/javax/swing/JFileChooser.java + test/javax/swing/JFileChooser/6342301/bug6342301.java Changeset: ca3bafeffd3b Author: rupashka Date: 2011-01-19 17:01 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/ca3bafeffd3b 6246816: SwingSet2 should be rewritten Reviewed-by: peterz ! make/common/Demo.gmk ! make/mkdemo/jfc/Makefile + make/mkdemo/jfc/SwingSet3/Makefile Changeset: e93106dc798b Author: lana Date: 2011-01-19 21:51 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/e93106dc798b Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/security/krb5/auto/basic.sh Changeset: b45ea2c3bd6d Author: rupashka Date: 2011-01-24 18:04 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/b45ea2c3bd6d 6735293: javax.swing.text.NavigationFilter.getNextVisualPositionFrom() not always throws BadLocationException Reviewed-by: peterz ! src/share/classes/javax/swing/text/View.java + test/javax/swing/text/NavigationFilter/6735293/bug6735293.java Changeset: 1f3ecbfa0c29 Author: lana Date: 2011-01-24 13:21 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/1f3ecbfa0c29 Merge Changeset: b8663921f5d7 Author: chegar Date: 2011-01-07 13:08 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/b8663921f5d7 7000511: PrintStream, PrintWriter, Formatter, Scanner leave files open when exception thrown Reviewed-by: alanb, mduigou ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Scanner.java ! test/ProblemList.txt + test/java/io/PrintStream/FailingConstructors.java + test/java/io/PrintWriter/FailingConstructors.java ! test/java/util/Formatter/Constructors.java + test/java/util/Formatter/FailingConstructors.java + test/java/util/Scanner/FailingConstructors.java Changeset: 5124c2a50539 Author: alanb Date: 2011-01-07 15:49 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/5124c2a50539 6993732: Remove the HPI Reviewed-by: ohair, lancea, chegar, mduigou, mchung, mr ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Defs.gmk ! make/common/Modules.gmk ! make/common/Release.gmk ! make/java/Makefile ! make/java/fdlibm/Makefile - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile ! make/tools/reorder/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c Changeset: ddaffd64796c Author: alanb Date: 2011-01-07 15:51 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/ddaffd64796c Merge Changeset: 6bf1c5958c22 Author: chegar Date: 2011-01-07 21:02 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/6bf1c5958c22 7009760: Possible stack corruption in Java_java_net_TwoStacksPlainSocketImpl_socketGetOption Summary: SOCKET_ADDRESS -> SOCKETADDRESS Reviewed-by: alanb ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c Changeset: 3dbc783a8073 Author: smarks Date: 2011-01-07 15:39 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/3dbc783a8073 7008728: diamond conversion of basic security, permissions, authentication Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/SolarisLoginModule.java ! src/share/classes/com/sun/security/auth/module/UnixLoginModule.java ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/CodeSource.java ! src/share/classes/java/security/Permissions.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/SecureClassLoader.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/UnresolvedPermission.java ! src/share/classes/java/security/UnresolvedPermissionCollection.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/sun/security/acl/AclEntryImpl.java ! src/share/classes/sun/security/acl/AclImpl.java ! src/share/classes/sun/security/acl/GroupImpl.java ! test/com/sun/security/auth/module/LdapLoginModule/CheckConfigs.java ! test/com/sun/security/auth/module/LdapLoginModule/CheckOptions.java Changeset: ee5bf287d0c4 Author: alanb Date: 2011-01-10 09:32 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/ee5bf287d0c4 7002957: (fc) FileChannel.transferTo fails to load libsendfile on Solaris 64-bit Reviewed-by: chegar ! make/java/nio/Makefile ! src/solaris/native/sun/nio/ch/FileChannelImpl.c Changeset: f4d755bbdabe Author: lancea Date: 2011-01-10 14:43 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/f4d755bbdabe 6544224: Remove the need of sun.reflect.misc Reviewed-by: alanb ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java Changeset: 2a0ff59928de Author: smarks Date: 2011-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/2a0ff59928de 7005608: diamond conversion of JCA and crypto providers Reviewed-by: wetmore ! src/share/classes/java/security/Security.java ! src/share/classes/sun/security/jca/ProviderList.java ! src/share/classes/sun/security/jca/Providers.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/provider/VerificationProvider.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/rsa/RSACore.java ! src/share/classes/sun/security/rsa/SunRsaSign.java Changeset: befe813e24d2 Author: lancea Date: 2011-01-11 12:36 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/befe813e24d2 7000693: java.sql.Timestamp compareTo() issues using low values Reviewed-by: okutsu ! src/share/classes/java/sql/Timestamp.java Changeset: 6d0217114886 Author: smarks Date: 2011-01-11 13:42 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/6d0217114886 7011095: revert diamond changes from 6880112 that occur in method args Reviewed-by: darcy, alanb ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/lang/StringCoding.java ! src/share/classes/java/util/logging/Logger.java Changeset: cb3ecb5e4ce5 Author: dl Date: 2011-01-12 14:40 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/cb3ecb5e4ce5 7005424: Resync java.util.concurrent classes with Dougs CVS - Jan 2011 Reviewed-by: dholmes, chegar, mduigou ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicMarkableReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java ! src/share/classes/java/util/concurrent/locks/Condition.java ! test/ProblemList.txt ! test/java/util/WeakHashMap/GCDuringIteration.java ! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java ! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java ! test/java/util/concurrent/Executors/AutoShutdown.java ! test/java/util/concurrent/Phaser/Basic.java + test/java/util/concurrent/Phaser/FickleRegister.java + test/java/util/concurrent/Phaser/PhaseOverflow.java + test/java/util/concurrent/Phaser/TieredArriveLoops.java ! test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java Changeset: a5a22f93e4c5 Author: smarks Date: 2011-01-12 13:52 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/a5a22f93e4c5 7008713: diamond conversion of kerberos5 and security tools Reviewed-by: weijun ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/Authenticator.java ! src/share/classes/sun/security/krb5/internal/AuthorizationData.java ! src/share/classes/sun/security/krb5/internal/EncAPRepPart.java ! src/share/classes/sun/security/krb5/internal/HostAddresses.java ! src/share/classes/sun/security/krb5/internal/KDCReq.java ! src/share/classes/sun/security/krb5/internal/KDCReqBody.java ! src/share/classes/sun/security/krb5/internal/KRBCred.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java ! src/share/classes/sun/security/krb5/internal/LastReq.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! test/sun/security/krb5/IPv6.java ! test/sun/security/krb5/auto/CleanState.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/LoginModuleOptions.java ! test/sun/security/krb5/tools/KtabCheck.java Changeset: f5c0b3cbee2f Author: kamg Date: 2011-01-12 11:47 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/f5c0b3cbee2f 6436034: Instance filter doesn't filter event if it occurs in native method Summary: Use 'GetLocalInstance' JVMTI extension if it exists Reviewed-by: coleenp, dcubed ! src/share/back/debugInit.c ! src/share/back/eventFilter.c ! src/share/instrument/JPLISAgent.c ! src/share/javavm/export/jvmti.h + test/com/sun/jdi/NativeInstanceFilter.java + test/com/sun/jdi/NativeInstanceFilterTarg.java Changeset: 295f6b861c12 Author: kamg Date: 2011-01-12 15:27 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/295f6b861c12 Merge Changeset: 538f913777cf Author: michaelm Date: 2011-01-13 11:01 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/538f913777cf 6896088: URLClassLoader.close() apparently not working for JAR URLs on Windows Reviewed-by: chegar ! src/share/classes/sun/misc/URLClassPath.java + test/java/net/URLClassLoader/B6896088.java Changeset: 9f265d55c1c4 Author: michaelm Date: 2011-01-13 11:02 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/9f265d55c1c4 Merge Changeset: 694951adefec Author: chegar Date: 2011-01-13 13:24 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/694951adefec 6964547: Impossible to set useV4 in SocksSocketImpl Summary: Add socksProxyVersion property Reviewed-by: alanb, michaelm ! make/sun/net/FILES_java.gmk ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/doc-files/net-properties.html + src/share/classes/sun/net/SocksProxy.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java + test/java/net/Socks/SocksProxyVersion.java Changeset: 38729ba6eb4f Author: michaelm Date: 2011-01-12 15:05 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/38729ba6eb4f 6829919: URLClassLoader.close() doesn't close resource file if getResourceAsStream(...) was called before Reviewed-by: chegar ! src/share/classes/java/net/URLClassLoader.java ! test/java/net/URLClassLoader/closetest/CloseTest.java + test/java/net/URLClassLoader/closetest/Common.java + test/java/net/URLClassLoader/closetest/GetResourceAsStream.java + test/java/net/URLClassLoader/closetest/build2.sh Changeset: ed390b2e5ca4 Author: michaelm Date: 2011-01-13 11:10 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/ed390b2e5ca4 Merge Changeset: 067b5f603fc8 Author: michaelm Date: 2011-01-13 14:41 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/067b5f603fc8 Merge Changeset: 3215b22cd90e Author: michaelm Date: 2011-01-13 16:33 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/3215b22cd90e 7003398: NetworkInterface equals() and hashCode() behaviors depend on permissions granted Reviewed-by: chegar, alanb ! src/share/classes/java/net/NetworkInterface.java + test/java/net/NetworkInterface/Equals.java Changeset: 29f2e311cce7 Author: mduigou Date: 2011-01-13 20:32 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/29f2e311cce7 6728865: Provide a better heuristics for Collections.disjoint method Reviewed-by: alanb, dholmes, chegar, forax ! src/share/classes/java/util/Collections.java Changeset: 59e352561146 Author: darcy Date: 2011-01-13 22:21 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/59e352561146 7012279: Project Coin: Clarify AutoCloseable and Throwable javadoc Reviewed-by: jjb ! src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Throwable.java Changeset: 983364897f72 Author: chegar Date: 2011-01-14 22:34 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/983364897f72 7010903: impl. of http.maxConnections is different from the description in JavaSE document Reviewed-by: alanb, michaelm ! src/share/classes/sun/net/www/http/KeepAliveCache.java Changeset: d61d9bf190f5 Author: smarks Date: 2011-01-14 15:31 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/d61d9bf190f5 7012003: diamond conversion for ssl Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHandlerTest.java Changeset: 507627325c81 Author: sundar Date: 2011-01-17 13:29 +0530 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/507627325c81 6508943: small typo in the documentation 6759414: javascript engine can not write to StringWriter 6869617: RhinoScriptEngine bug : ScriptException cause not set (with fix) 7012701: Add a test to check that Rhino's RegExp parser accepts unescaped '[' Reviewed-by: alanb, jjh ! src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java ! src/share/classes/javax/script/CompiledScript.java + test/javax/script/CauseExceptionTest.java + test/javax/script/StringWriterPrintTest.java + test/javax/script/UnescapedBracketRegExTest.java Changeset: 9596a600758c Author: lana Date: 2011-01-19 19:00 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/9596a600758c Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java Changeset: e64b1f11cd0b Author: chegar Date: 2011-01-20 15:23 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/e64b1f11cd0b 7011857: java/util/concurrent/Phaser/FickleRegister.java fails on solaris-sparc Summary: Remove from ProblemList, failure resolved by 7009231 Reviewed-by: alanb ! test/ProblemList.txt Changeset: cc195c981ae2 Author: mchung Date: 2011-01-20 22:17 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/cc195c981ae2 7013739: jdk_rmi target is missing in the top repo's test/Makefile Reviewed-by: ohair, igor ! test/ProblemList.txt Changeset: 2a8d1a0a2418 Author: chegar Date: 2011-01-21 17:02 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/2a8d1a0a2418 7012768: InetAddress lookupTable leaks/deadlocks when using unsupported name service spi Reviewed-by: alanb, michaelm ! src/share/classes/java/net/InetAddress.java - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/chaining/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/net/InetAddress/nameservice/chaining/Providers.java + test/sun/net/InetAddress/nameservice/chaining/Simple1NameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/chaining/Simple2NameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/chaining/SimpleNameService.java + test/sun/net/InetAddress/nameservice/deadlock/Hang.java + test/sun/net/InetAddress/nameservice/deadlock/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/net/InetAddress/nameservice/deadlock/ThrowingNameService.java + test/sun/net/InetAddress/nameservice/deadlock/ThrowingNameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/simple/CacheTest.java + test/sun/net/InetAddress/nameservice/simple/DefaultCaching.java + test/sun/net/InetAddress/nameservice/simple/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/net/InetAddress/nameservice/simple/SimpleNameService.java + test/sun/net/InetAddress/nameservice/simple/SimpleNameServiceDescriptor.java Changeset: 6a7b8406a1b9 Author: chegar Date: 2011-01-21 17:04 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/6a7b8406a1b9 Merge Changeset: f26d1a7fe4d2 Author: mchung Date: 2011-01-21 09:43 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/f26d1a7fe4d2 6912013: Remove the temporary launcher fix to add modules in the bootclasspath Reviewed-by: ksrini ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/classes/sun/launcher/LauncherHelper.java Changeset: 9c18818e7a5f Author: mchung Date: 2011-01-21 09:45 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/9c18818e7a5f Merge - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 2381e810330b Author: zgu Date: 2011-01-20 10:45 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/2381e810330b 6983248: net/net001 and net/net003 fail on WinXP with JDK7-B108 Summary: Using closesocket to close socket handler to avoid invalid C runtime parameter exception. Reviewed-by: alanb, phh, dcubed, dsamersoff, coleenp, acorn ! src/windows/demo/jvmti/hprof/hprof_md.c Changeset: d03e47de3a89 Author: zgu Date: 2011-01-21 11:38 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/d03e47de3a89 Merge Changeset: c73c178159d8 Author: phh Date: 2011-01-20 19:34 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/c73c178159d8 6173675: M&M: approximate memory allocation rate/amount per thread Summary: Subclass com.sun.management.ThreadMXBean from java.lang.management.ThreadMXBean, add getAllocatedBytes() and friends to c.s.m.ThreadMXBean and have sun.management.ThreadImpl implement c.s.m.ThreadMXBean rather than j.l.m.ThreadMXBean. Reviewed-by: mchung, alanb, dholmes, emcmanus ! make/java/management/mapfile-vers + src/share/classes/com/sun/management/ThreadMXBean.java ! src/share/classes/sun/management/ThreadImpl.java ! src/share/classes/sun/management/VMManagement.java ! src/share/classes/sun/management/VMManagementImpl.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/ThreadImpl.c ! src/share/native/sun/management/VMManagementImpl.c + test/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java + test/com/sun/management/ThreadMXBean/ThreadAllocatedMemoryArray.java + test/com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java Changeset: 64ef2f52d781 Author: phh Date: 2011-01-21 07:29 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/64ef2f52d781 7013682: two test checking cpuTime filed java/lang/management/ThreadMXBean Summary: Typo in 6173675 fix dropped getThreadCpuTime(long) result on the floor. Reviewed-by: mchung, dholmes ! src/share/classes/sun/management/ThreadImpl.java Changeset: cd13b2114f2e Author: phh Date: 2011-01-22 08:42 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/cd13b2114f2e Merge ! src/share/classes/sun/management/ThreadImpl.java Changeset: d1365fdfb3ea Author: phh Date: 2011-01-22 08:43 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/d1365fdfb3ea Merge - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 4cc447291326 Author: sherman Date: 2011-01-24 11:47 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/4cc447291326 7006576: (zipfs) Path.exists() always returns false on dirs when zip/JAR file built without dirs 7009092: (zipfs) ZipPath.isSameFile() should always return true if this Path and the given Path are equal. 7009085: (zipfs) ZipPath.normalize("/./.") returns null. 7009102: (zipfs) ZipPath.toRealPath() should always return absolute path. Summary: zip filesystem provider update Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java ! test/demo/zipfs/PathOps.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: 1f977c82b733 Author: lana Date: 2011-01-24 13:24 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/1f977c82b733 Merge ! make/common/Defs-windows.gmk - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 47cfd89c3227 Author: lana Date: 2011-01-28 10:04 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/47cfd89c3227 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 006c683ead1a Author: ohair Date: 2011-01-05 14:28 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/006c683ead1a 6975326: Problem in install/make/rebase/Makefile, grep on empty pattern 6413588: Add 'ldd -r' and 'dump -Lv' checks to all .so files delivered in the JDK 7000995: Add check in makefiles to verify that msvcp100.dll is NOT used Reviewed-by: mduigou ! make/com/sun/java/pack/Makefile ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/java/redist/Makefile Changeset: 9576644931b2 Author: ohair Date: 2011-01-07 21:52 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/9576644931b2 6980024: Rebranding jre7/jdk7 License, Copyright, Readme 6912291: Third party license agreement should be present in all bundles Reviewed-by: katleman ! make/common/Modules.gmk ! make/common/Release.gmk ! make/common/shared/Defs-control.gmk Changeset: 8c3c6ac6fcdb Author: ohair Date: 2011-01-10 09:59 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/8c3c6ac6fcdb Merge Changeset: 658559ca4526 Author: ohair Date: 2011-01-10 17:00 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/658559ca4526 7011382: Fix use of VS100COMNTOOLS when installed in non-default or non-space path Reviewed-by: prr ! make/common/shared/Defs-windows.gmk Changeset: fd6319676bd3 Author: ohair Date: 2011-01-10 17:53 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/fd6319676bd3 Merge Changeset: 713d20f796c0 Author: ohair Date: 2011-01-10 18:07 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/713d20f796c0 6989472: Provide simple jdk identification information in the install image Reviewed-by: alanb ! make/common/Release.gmk ! make/common/shared/Defs-versions.gmk Changeset: 523386cfb731 Author: ohair Date: 2011-01-10 22:26 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/523386cfb731 Merge Changeset: 83cef4633684 Author: ohair Date: 2011-01-13 17:51 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/83cef4633684 Merge Changeset: 4241588a12c3 Author: ohair Date: 2011-01-13 13:49 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/4241588a12c3 7008047: remove sanity check of msival tool from JDK tree Reviewed-by: billyh ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk Changeset: 81e66ce6f501 Author: ohair Date: 2011-01-13 23:58 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/81e66ce6f501 Merge Changeset: 0c29bbd10e19 Author: ohair Date: 2011-01-14 14:04 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/0c29bbd10e19 6950375: Remove msvcrt.dll from the Windows JRE bundles Reviewed-by: prr ! make/Makefile ! make/common/Defs-windows.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/java/redist/Makefile ! make/jdk_generic_profile.sh ! src/share/demo/jvmti/index.html Changeset: 329f49ab5c4c Author: ohair Date: 2011-01-16 12:10 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/329f49ab5c4c Merge Changeset: 688f415db098 Author: ohair Date: 2011-01-26 16:05 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/688f415db098 Merge Changeset: aecb8f0eb83b Author: ohair Date: 2011-01-27 18:43 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/aecb8f0eb83b Merge Changeset: f08682e23279 Author: ohair Date: 2011-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/f08682e23279 Merge ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Modules.gmk ! make/common/Program.gmk ! make/common/Release.gmk Changeset: 07c68a15ec79 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/07c68a15ec79 Added tag jdk7-b128 for changeset f08682e23279 ! .hgtags Changeset: 001dcfd0be4b Author: ohair Date: 2011-02-08 16:30 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/001dcfd0be4b 7016976: Documentation for required ant version on JDK7 builds on Solaris 10 and Solaris 11 Reviewed-by: rinaldo ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity.gmk Changeset: 1f056ddda771 Author: ohair Date: 2011-01-28 14:32 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/1f056ddda771 7014301: Change make 3.81 sanity check to a fatal, 3.81 is needed now Reviewed-by: alanb ! make/common/shared/Sanity.gmk Changeset: 3f77dae85c85 Author: ohair Date: 2011-02-08 13:06 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/3f77dae85c85 Merge Changeset: 14cd5d54a8d0 Author: ohair Date: 2011-02-08 20:00 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/14cd5d54a8d0 Merge ! make/common/shared/Sanity.gmk Changeset: 326aac19a89f Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/326aac19a89f Added tag jdk7-b129 for changeset 14cd5d54a8d0 ! .hgtags Changeset: bad0ddc6f573 Author: prr Date: 2011-01-26 11:46 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/bad0ddc6f573 7014738: Update jdk repo application manifests with Windows 7 compatibility section. Reviewed-by: bae, igor ! src/windows/resource/java.manifest Changeset: d0e158473b6f Author: prr Date: 2011-01-26 13:26 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/d0e158473b6f 6940890: Java doesn't pick up the correct fontconfig files in latest Solaris Next builds Reviewed-by: bae, igor ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java Changeset: 4cf20706dbfa Author: dlila Date: 2011-01-27 16:43 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/4cf20706dbfa 4645692: solveCubic does not return all solutions. Summary: more robust solveCubic implementation. Reviewed-by: flar ! src/share/classes/java/awt/geom/CubicCurve2D.java + test/java/awt/geom/CubicCurve2D/ContainsTest.java + test/java/awt/geom/CubicCurve2D/IntersectsTest.java + test/java/awt/geom/CubicCurve2D/SolveCubicTest.java Changeset: 21621a756b32 Author: lana Date: 2011-02-03 19:15 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/21621a756b32 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 5e624003e622 Author: dlila Date: 2011-02-08 09:22 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/5e624003e622 7016856: dashing performance was reduced during latest changes to the OpenJDK rasterizer Summary: Optimized dashing, rasterizing, and the flow of transformed coordinates Reviewed-by: flar ! src/share/classes/sun/java2d/pisces/Curve.java ! src/share/classes/sun/java2d/pisces/Dasher.java ! src/share/classes/sun/java2d/pisces/Helpers.java ! src/share/classes/sun/java2d/pisces/PiscesCache.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java ! src/share/classes/sun/java2d/pisces/Renderer.java ! src/share/classes/sun/java2d/pisces/Stroker.java ! src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java Changeset: 577c5d930e44 Author: dav Date: 2011-01-25 15:33 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/577c5d930e44 6693961: cross-window focus transfer ability in the Focus Spec should be revised Reviewed-by: ant, art ! src/share/classes/java/awt/doc-files/FocusSpec.html Changeset: 5f3615691623 Author: dav Date: 2011-01-25 19:07 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/5f3615691623 6431076: Cursor gets reset to text cursor in xawt TextArea when autoscrolling on append Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XGlobalCursorManager.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java + test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test.java + test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test1.java Changeset: 6fd2d28e66cd Author: denis Date: 2011-01-28 16:52 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/6fd2d28e66cd 6340263: Regression testcase java/awt/dnd/DnDClipboardDeadlockTest throughs IOException: Owner timed out Reviewed-by: anthony, art ! src/solaris/classes/sun/awt/X11/XSelection.java Changeset: 9da15efec22b Author: andrew Date: 2011-02-01 17:44 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/9da15efec22b 7015232: missing copyright header in CheckZOrderChange.java Summary: Add standard GPL header as on other tests Reviewed-by: anthony ! test/java/awt/Container/CheckZOrderChange/CheckZOrderChange.java Changeset: 3244848a4a2b Author: dav Date: 2011-02-04 17:32 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/3244848a4a2b 6741526: KeyboardFocusManager.setDefaultFocusTraversalPolicy(FocusTraversalPolicy) affects created components Reviewed-by: ant, dcherepanov ! src/share/classes/java/awt/Window.java + test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_AWT.java + test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java Changeset: b5fc02e1a944 Author: lana Date: 2011-02-08 14:19 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/b5fc02e1a944 Merge Changeset: 69fac04eda38 Author: rupashka Date: 2011-01-27 14:23 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/69fac04eda38 6902615: Method JTextComponent.getKeyStrokesForAction() throws StackOverflowError Reviewed-by: peterz ! src/share/classes/javax/swing/text/Keymap.java Changeset: ec066e903b84 Author: rupashka Date: 2011-01-27 14:33 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/ec066e903b84 6935155: @since tag is missing in JTextComponent.save/restoreComposedText Reviewed-by: alexp ! src/share/classes/javax/swing/text/JTextComponent.java Changeset: 457f6b2cc155 Author: malenkov Date: 2011-01-31 21:22 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/457f6b2cc155 7001484: DOC: Method javax.swing.border.StrokeBorder.getBorderInsets() should specify how it converts float Reviewed-by: alexp ! src/share/classes/javax/swing/border/StrokeBorder.java Changeset: 020b4695370c Author: malenkov Date: 2011-01-31 21:31 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/020b4695370c 7001118: DOC: javax.swing.border.StrokeBorder.paintBorder() doesn't throw NPE in all specified cases Reviewed-by: alexp ! src/share/classes/javax/swing/border/StrokeBorder.java Changeset: 07bea0d4e454 Author: malenkov Date: 2011-01-31 21:49 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/07bea0d4e454 6999045: DOC: Unclear spec for BevelBorder constructor and BorderFactory factory method (colors switching) Reviewed-by: alexp ! src/share/classes/javax/swing/BorderFactory.java ! src/share/classes/javax/swing/border/BevelBorder.java Changeset: cbcd461067c5 Author: rupashka Date: 2011-02-02 18:37 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/cbcd461067c5 6988168: Press the "Toggle Font" button.The size of the combo box didn't change. Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java Changeset: 6c4b6780ab20 Author: rupashka Date: 2011-02-02 18:41 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/6c4b6780ab20 6988176: There is focus painted inside the button. Reviewed-by: alexp ! src/share/classes/sun/swing/WindowsPlacesBar.java Changeset: 057e9b837105 Author: rupashka Date: 2011-02-03 16:30 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/057e9b837105 7013453: BufferStrategyPaintManager.dispose will cause IllegalMonitorStateException in event thread Reviewed-by: alexp ! src/share/classes/javax/swing/BufferStrategyPaintManager.java + test/javax/swing/RepaintManager/7013453/bug7013453.java Changeset: 0fae79ec7248 Author: naoto Date: 2011-02-03 09:59 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/0fae79ec7248 7013282: No appropriate CCC request for listed JDK 7 changes in java.util.spi package (b121) Reviewed-by: peytoia ! src/share/classes/java/util/spi/LocaleNameProvider.java Changeset: c7e368a95c75 Author: alexp Date: 2011-02-07 21:15 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/c7e368a95c75 7016942: Revert a refactoring in TooltipManager to allow reflection hack Reviewed-by: rupashka ! src/share/classes/javax/swing/ToolTipManager.java Changeset: 989f6d3eee0d Author: alexp Date: 2011-02-07 21:34 +0300 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/989f6d3eee0d 6979537: closed/javax/swing/JSplitPane/UnitTest/UnitTest.java fails Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java Changeset: 842a0f8c89ea Author: naoto Date: 2011-02-08 09:04 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/842a0f8c89ea 7015500: Locale.toLanguageTag() uses "und" as lang subtag for private use only Locale Reviewed-by: srl ! src/share/classes/java/util/Locale.java ! src/share/classes/sun/util/locale/LanguageTag.java ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: d002fe0c57c5 Author: lana Date: 2011-02-08 14:19 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/d002fe0c57c5 Merge Changeset: dbfc1e419cb2 Author: darcy Date: 2011-01-24 20:04 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/dbfc1e419cb2 7006578: Project Coin: Retrofit JDK libraries with @SafeVarargs Reviewed-by: mduigou, alexp ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/sun/swing/AccumulativeRunnable.java Changeset: ae38d1374e31 Author: mullan Date: 2011-01-24 14:56 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/ae38d1374e31 5001004: Required Security Algorithms need to be defined Reviewed-by: wetmore ! src/share/classes/java/security/AlgorithmParameterGenerator.java ! src/share/classes/java/security/AlgorithmParameters.java ! src/share/classes/java/security/KeyFactory.java ! src/share/classes/java/security/KeyPairGenerator.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/MessageDigest.java ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/SecureRandom.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/Signature.java ! src/share/classes/java/security/cert/CertPath.java ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/CertStore.java ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/CertificateFactory.java ! src/share/classes/java/security/cert/CertificateFactorySpi.java ! src/share/classes/java/security/cert/package.html ! src/share/classes/java/security/package.html ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/ExemptionMechanism.java ! src/share/classes/javax/crypto/KeyAgreement.java ! src/share/classes/javax/crypto/KeyGenerator.java ! src/share/classes/javax/crypto/Mac.java ! src/share/classes/javax/crypto/SecretKeyFactory.java ! src/share/classes/javax/crypto/package.html ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/net/ssl/package.html ! src/share/classes/javax/security/auth/login/Configuration.java ! src/share/classes/javax/security/auth/login/package.html Changeset: b33e9b15835e Author: mullan Date: 2011-01-24 15:08 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/b33e9b15835e Merge - make/common/internal/BinaryPlugs.gmk - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/classes/java/dyn/JavaMethodHandle.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java ! src/share/classes/java/security/Security.java ! src/share/classes/javax/net/ssl/SSLContext.java - src/share/classes/sun/java2d/pisces/LineSink.java - src/share/classes/sun/net/httpserver/SelectorCache.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java - test/sun/security/krb5/auto/basic.sh Changeset: 6ac9383640c6 Author: mullan Date: 2011-01-24 15:46 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/6ac9383640c6 Merge Changeset: 6e7bed89ce84 Author: mullan Date: 2011-01-25 08:41 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/6e7bed89ce84 Merge Changeset: bf1b937076db Author: alanb Date: 2011-01-26 18:01 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/bf1b937076db 7012663: javadoc warning in javax.swing.JComponent and javax.swing.plaf.synth.SynthTextPaneUI Reviewed-by: alexp ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java Changeset: abab55565eda Author: darcy Date: 2011-01-26 12:32 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/abab55565eda 7013420: Project Coin: remove general expression support from try-with-resources statement Reviewed-by: alanb ! test/java/nio/channels/FileChannel/Truncate.java Changeset: 236e3f2d0a6b Author: alanb Date: 2011-01-28 09:28 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/236e3f2d0a6b 7006126: (fs) Updates to file system API (1/2011) Reviewed-by: chegar, sherman ! make/java/java/FILES_java.gmk ! make/java/nio/FILES_java.gmk ! make/mkdemo/Makefile ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/SerialCallbackContext.java - src/share/classes/java/io/TempFileHelper.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/SeekableByteChannel.java ! src/share/classes/java/nio/file/AccessMode.java + src/share/classes/java/nio/file/CopyMoveHelper.java ! src/share/classes/java/nio/file/CopyOption.java ! src/share/classes/java/nio/file/DirectoryStream.java - src/share/classes/java/nio/file/FileRef.java ! src/share/classes/java/nio/file/FileStore.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/FileSystems.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/FileVisitor.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/LinkOption.java ! src/share/classes/java/nio/file/LinkPermission.java ! src/share/classes/java/nio/file/OpenOption.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/PathMatcher.java ! src/share/classes/java/nio/file/Paths.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java + src/share/classes/java/nio/file/TempFileHelper.java ! src/share/classes/java/nio/file/WatchEvent.java ! src/share/classes/java/nio/file/WatchKey.java ! src/share/classes/java/nio/file/WatchService.java ! src/share/classes/java/nio/file/attribute/AclEntry.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java - src/share/classes/java/nio/file/attribute/Attributes.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java ! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java ! src/share/classes/java/nio/file/attribute/DosFileAttributes.java ! src/share/classes/java/nio/file/attribute/FileAttribute.java ! src/share/classes/java/nio/file/attribute/FileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileOwnerAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java ! src/share/classes/java/nio/file/attribute/FileTime.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributes.java ! src/share/classes/java/nio/file/attribute/PosixFilePermission.java ! src/share/classes/java/nio/file/attribute/PosixFilePermissions.java ! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java ! src/share/classes/java/nio/file/attribute/package-info.java ! src/share/classes/java/nio/file/package-info.java ! src/share/classes/java/nio/file/spi/FileSystemProvider.java ! src/share/classes/java/nio/file/spi/FileTypeDetector.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/sun/nio/fs/AbstractAclFileAttributeView.java ! src/share/classes/sun/nio/fs/AbstractBasicFileAttributeView.java + src/share/classes/sun/nio/fs/AbstractFileSystemProvider.java ! src/share/classes/sun/nio/fs/AbstractFileTypeDetector.java ! src/share/classes/sun/nio/fs/AbstractPath.java ! src/share/classes/sun/nio/fs/AbstractPoller.java ! src/share/classes/sun/nio/fs/AbstractUserDefinedFileAttributeView.java ! src/share/classes/sun/nio/fs/AbstractWatchKey.java ! src/share/classes/sun/nio/fs/AbstractWatchService.java ! src/share/classes/sun/nio/fs/DynamicFileAttributeView.java ! src/share/classes/sun/nio/fs/FileOwnerAttributeViewImpl.java ! src/share/classes/sun/nio/fs/PollingWatchService.java ! src/share/classes/sun/security/provider/SeedGenerator.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/sample/nio/file/AclEdit.java ! src/share/sample/nio/file/Chmod.java ! src/share/sample/nio/file/Copy.java ! src/share/sample/nio/file/DiskUsage.java ! src/share/sample/nio/file/FileType.java ! src/share/sample/nio/file/WatchDir.java ! src/share/sample/nio/file/Xdd.java ! src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxWatchService.java ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! src/solaris/classes/sun/nio/fs/UnixCopyFile.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java ! src/windows/classes/sun/nio/fs/RegistryFileTypeDetector.java ! src/windows/classes/sun/nio/fs/WindowsFileAttributeViews.java ! src/windows/classes/sun/nio/fs/WindowsFileCopy.java ! src/windows/classes/sun/nio/fs/WindowsFileStore.java ! src/windows/classes/sun/nio/fs/WindowsFileSystem.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! src/windows/classes/sun/nio/fs/WindowsPathParser.java ! src/windows/classes/sun/nio/fs/WindowsSecurityDescriptor.java ! src/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java ! src/windows/classes/sun/nio/fs/WindowsWatchService.java ! test/demo/zipfs/basic.sh ! test/java/io/File/IsHidden.java ! test/java/io/File/SetAccess.java ! test/java/io/File/SymLinks.java ! test/java/io/FileInputStream/LargeFileAvailable.java ! test/java/nio/channels/FileChannel/AtomicAppend.java ! test/java/nio/channels/FileChannel/Transfer.java ! test/java/nio/file/DirectoryStream/Basic.java ! test/java/nio/file/DirectoryStream/DriveLetter.java ! test/java/nio/file/DirectoryStream/SecureDS.java ! test/java/nio/file/FileStore/Basic.java + test/java/nio/file/Files/BytesAndLines.java + test/java/nio/file/Files/CheckPermissions.java - test/java/nio/file/Files/ContentType.java + test/java/nio/file/Files/CopyAndMove.java - test/java/nio/file/Files/CreateFileTree.java + test/java/nio/file/Files/DeleteOnClose.java + test/java/nio/file/Files/FileAttributes.java - test/java/nio/file/Files/ForceLoad.java + test/java/nio/file/Files/InterruptCopy.java + test/java/nio/file/Files/Links.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java ! test/java/nio/file/Files/Misc.java + test/java/nio/file/Files/PassThroughFileSystem.java - test/java/nio/file/Files/PrintFileTree.java + test/java/nio/file/Files/SBC.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java + test/java/nio/file/Files/TemporaryFiles.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java + test/java/nio/file/Files/delete_on_close.sh - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy + test/java/nio/file/Files/probeContentType/Basic.java + test/java/nio/file/Files/probeContentType/ForceLoad.java + test/java/nio/file/Files/probeContentType/META-INF/services/java.nio.file.spi.FileTypeDetector + test/java/nio/file/Files/probeContentType/SimpleFileTypeDetector.java + test/java/nio/file/Files/walkFileTree/CreateFileTree.java + test/java/nio/file/Files/walkFileTree/MaxDepth.java + test/java/nio/file/Files/walkFileTree/Nulls.java + test/java/nio/file/Files/walkFileTree/PrintFileTree.java + test/java/nio/file/Files/walkFileTree/SkipSiblings.java + test/java/nio/file/Files/walkFileTree/TerminateWalk.java + test/java/nio/file/Files/walkFileTree/WalkWithSecurity.java + test/java/nio/file/Files/walkFileTree/denyAll.policy + test/java/nio/file/Files/walkFileTree/grantAll.policy + test/java/nio/file/Files/walkFileTree/grantTopOnly.policy + test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java ! test/java/nio/file/Path/Misc.java - test/java/nio/file/Path/PassThroughFileSystem.java ! test/java/nio/file/Path/PathOps.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh ! test/java/nio/file/TestUtil.java ! test/java/nio/file/WatchService/Basic.java ! test/java/nio/file/WatchService/FileTreeModifier.java ! test/java/nio/file/WatchService/LotsOfEvents.java ! test/java/nio/file/WatchService/SensitivityModifier.java ! test/java/nio/file/attribute/AclFileAttributeView/Basic.java ! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java ! test/java/nio/file/attribute/DosFileAttributeView/Basic.java - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java ! test/java/nio/file/attribute/FileTime/Basic.java ! test/java/nio/file/attribute/PosixFileAttributeView/Basic.java ! test/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java ! test/java/nio/file/spi/SetDefaultProvider.java ! test/java/nio/file/spi/TestProvider.java Changeset: 60d347deb54d Author: alanb Date: 2011-01-28 09:31 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/60d347deb54d Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java ! test/demo/zipfs/basic.sh - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: dea360853f8b Author: alanb Date: 2011-01-28 13:26 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/dea360853f8b 7015410: test/java/net/Socks/SocksProxyVersion.java needs to be updated due to 7013420 Reviewed-by: chegar ! test/java/net/Socks/SocksProxyVersion.java Changeset: d21a1ce074a7 Author: darcy Date: 2011-01-28 17:09 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/d21a1ce074a7 7015156: Remove JSR 308 changes from core libraries Reviewed-by: mduigou ! src/share/classes/java/lang/SuppressWarnings.java ! src/share/classes/java/lang/annotation/ElementType.java Changeset: f110edeb4428 Author: darcy Date: 2011-02-01 00:29 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/f110edeb4428 7015827: Fix HTML validation issues in java.math package Reviewed-by: mduigou ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/RoundingMode.java Changeset: d4bc38aa7594 Author: xuelei Date: 2011-02-01 04:45 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/d4bc38aa7594 7011497: new CertPathValidatorException.BasicReason enum constant for constrained algorithm Summary: add new BasicReason and improve trust anchor searching method during cert path validation Reviewed-by: mullan ! src/share/classes/java/security/cert/CertPathValidatorException.java + src/share/classes/sun/security/provider/certpath/AdaptableX509CertSelector.java ! src/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/validator/SimpleValidator.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java Changeset: 21d7cd823247 Author: sundar Date: 2011-02-01 21:00 +0530 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/21d7cd823247 7015908: 3 javax.script tests fail with openjdk build Reviewed-by: alanb ! test/javax/script/CauseExceptionTest.java ! test/javax/script/StringWriterPrintTest.java ! test/javax/script/UnescapedBracketRegExTest.java Changeset: 312dc0abb960 Author: sherman Date: 2011-02-01 14:20 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/312dc0abb960 7015391: (zipfs) Update zip provider for 1/2011 changes 7014948: (zipfs) ZipFileSystem.newFileSystem(Path...) should not throw FileSystemAlreadyExistsException 7015139: (zipfs) ZipPath.delete() should throw DirectoryNotEmptyException when handling "real, non-empty" dir Summary: zip filesystem provider update Reviewed-by: alanb ! make/mkdemo/Makefile ! src/share/demo/nio/zipfs/Demo.java ! src/share/demo/nio/zipfs/README.txt ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributeView.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java - src/share/demo/zipfs ! test/demo/zipfs/Basic.java ! test/demo/zipfs/PathOps.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: 25462d7eee24 Author: briangoetz Date: 2011-02-02 13:13 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/25462d7eee24 7012540: java.util.Objects.nonNull() incorrectly named Reviewed-by: darcy, weijun ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/lang/StackTraceElement.java ! src/share/classes/java/nio/file/DirectoryIteratorException.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Objects.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! test/java/util/Objects/BasicObjectsTest.java Changeset: 3c86f24f7500 Author: chegar Date: 2011-02-03 10:10 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/3c86f24f7500 7008595: Class loader leak caused by keepAliveTimer thread in KeepAliveCache Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/KeepAliveCache.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java Changeset: dff9b6d18628 Author: coffeys Date: 2011-02-03 11:28 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/dff9b6d18628 7016897: Copyright header correction : test/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java Reviewed-by: vinnie ! test/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java Changeset: 0f5dc2fc81b1 Author: chegar Date: 2011-02-03 11:56 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/0f5dc2fc81b1 6887710: Jar index should avoid putting META-INF in the INDEX.LIST Reviewed-by: michaelm ! src/share/classes/sun/misc/JarIndex.java + test/sun/misc/JarIndex/metaInfFilenames/Basic.java + test/sun/misc/JarIndex/metaInfFilenames/jarA/META-INF/services/my.happy.land + test/sun/misc/JarIndex/metaInfFilenames/jarA/a/A.java + test/sun/misc/JarIndex/metaInfFilenames/jarA/com/message/spi/MessageService.java + test/sun/misc/JarIndex/metaInfFilenames/jarB/META-INF/JAVA2.DS + test/sun/misc/JarIndex/metaInfFilenames/jarB/META-INF/services/no.name.service + test/sun/misc/JarIndex/metaInfFilenames/jarB/b/B.java + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/fonts.mf + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/fonts/Company-corporate.ttf + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/fonts/kidpr.ttf + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/services/com.message.spi.MessageService + test/sun/misc/JarIndex/metaInfFilenames/jarC/my/impl/StandardMessageService.java Changeset: 68e3eba12afe Author: michaelm Date: 2011-02-03 12:57 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/68e3eba12afe 6751021: TEST_BUG: race condition in the test java/lang/Runtime/exec/Duped.java Reviewed-by: alanb ! test/java/lang/Runtime/exec/Duped.java Changeset: e2a182adb30f Author: alanb Date: 2011-02-03 13:37 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/e2a182adb30f 7014794: (file) lookupPrincipalByGroupName fails to find large NIS groups Reviewed-by: chegar ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c Changeset: 515512634eb4 Author: vinnie Date: 2011-02-03 19:09 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/515512634eb4 6997561: A request for better error handling in JNDI Reviewed-by: robm ! src/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java + test/com/sun/jndi/ldap/LdapName/EmptyNameSearch.java Changeset: 035ecca4379c Author: sherman Date: 2011-02-03 13:49 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/035ecca4379c 7014645: Support perl style Unicode hex notation \x{...} Summary: Added the construct \x{...} for Unicode hex notation support Reviewed-by: alanb, okutsu ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java Changeset: 3c1eca364cc7 Author: ksrini Date: 2011-02-03 15:41 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/3c1eca364cc7 6968053: (launcher) hide exceptions under certain launcher failures Reviewed-by: mchung ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/misc/VM.java ! test/tools/launcher/Arrrghs.java Changeset: 1b5c838b8db8 Author: vinnie Date: 2011-02-04 00:33 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/1b5c838b8db8 6989705: ECC security code native code compiler warnings Reviewed-by: alanb, ohair ! src/share/native/sun/security/ec/ECC_JNI.cpp ! src/share/native/sun/security/ec/impl/ec.c ! src/share/native/sun/security/ec/impl/ec.h ! src/share/native/sun/security/ec/impl/ec2.h ! src/share/native/sun/security/ec/impl/ec2_163.c ! src/share/native/sun/security/ec/impl/ec2_193.c ! src/share/native/sun/security/ec/impl/ec2_233.c ! src/share/native/sun/security/ec/impl/ec2_aff.c ! src/share/native/sun/security/ec/impl/ec2_mont.c ! src/share/native/sun/security/ec/impl/ec_naf.c ! src/share/native/sun/security/ec/impl/ecc_impl.h ! src/share/native/sun/security/ec/impl/ecdecode.c ! src/share/native/sun/security/ec/impl/ecl-curve.h ! src/share/native/sun/security/ec/impl/ecl-exp.h ! src/share/native/sun/security/ec/impl/ecl-priv.h ! src/share/native/sun/security/ec/impl/ecl.c ! src/share/native/sun/security/ec/impl/ecl.h ! src/share/native/sun/security/ec/impl/ecl_curve.c ! src/share/native/sun/security/ec/impl/ecl_gf.c ! src/share/native/sun/security/ec/impl/ecl_mult.c ! src/share/native/sun/security/ec/impl/ecp.h ! src/share/native/sun/security/ec/impl/ecp_192.c ! src/share/native/sun/security/ec/impl/ecp_224.c ! src/share/native/sun/security/ec/impl/ecp_256.c ! src/share/native/sun/security/ec/impl/ecp_384.c ! src/share/native/sun/security/ec/impl/ecp_521.c ! src/share/native/sun/security/ec/impl/ecp_aff.c ! src/share/native/sun/security/ec/impl/ecp_jac.c ! src/share/native/sun/security/ec/impl/ecp_jm.c ! src/share/native/sun/security/ec/impl/ecp_mont.c ! src/share/native/sun/security/ec/impl/logtab.h ! src/share/native/sun/security/ec/impl/mp_gf2m-priv.h ! src/share/native/sun/security/ec/impl/mp_gf2m.c ! src/share/native/sun/security/ec/impl/mp_gf2m.h ! src/share/native/sun/security/ec/impl/mpi-config.h ! src/share/native/sun/security/ec/impl/mpi-priv.h ! src/share/native/sun/security/ec/impl/mpi.c ! src/share/native/sun/security/ec/impl/mpi.h ! src/share/native/sun/security/ec/impl/mplogic.c ! src/share/native/sun/security/ec/impl/mplogic.h ! src/share/native/sun/security/ec/impl/mpmontg.c ! src/share/native/sun/security/ec/impl/mpprime.h ! src/share/native/sun/security/ec/impl/oid.c ! src/share/native/sun/security/ec/impl/secitem.c ! src/share/native/sun/security/ec/impl/secoidt.h Changeset: fed61c2f4d14 Author: vinnie Date: 2011-02-04 00:33 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/fed61c2f4d14 Merge Changeset: 78fe1b7a9a1a Author: vinnie Date: 2011-02-04 09:52 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/78fe1b7a9a1a 7017176: Several JNDI tests are mssing GPL header Reviewed-by: alanb ! test/com/sun/jndi/ldap/LdapName/Case.java ! test/com/sun/jndi/ldap/LdapName/EmptyNameSearch.java ! test/com/sun/jndi/ldap/LdapName/UnescapeTest.java ! test/com/sun/jndi/ldap/ReadTimeoutTest.java Changeset: 9599534b1727 Author: lancea Date: 2011-02-04 09:07 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/9599534b1727 7014095: Broken link in java.sql package specification Reviewed-by: alanb ! src/share/classes/java/sql/package.html Changeset: c5f953e920c6 Author: mduigou Date: 2011-02-04 12:54 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/c5f953e920c6 7015783: Update JDK Netbeans projects to -source 1.7 Reviewed-by: darcy ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent Changeset: b8662dac7c91 Author: sherman Date: 2011-02-04 13:17 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/b8662dac7c91 7005986: (zipfs) ZipPath.startsWith() fails because of the implementation of getName(index) Summary: Updated starsWith/endsWith to be consistent with default file system Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java ! test/demo/zipfs/PathOps.java ! test/demo/zipfs/basic.sh Changeset: a775b8d3fed0 Author: lana Date: 2011-02-04 17:29 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/a775b8d3fed0 Merge - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties Changeset: b0bd638036bd Author: vinnie Date: 2011-02-07 09:11 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/b0bd638036bd 7017486: Need synchronized access when flushing the LDAP request queue Reviewed-by: alanb ! src/share/classes/com/sun/jndi/ldap/Connection.java Changeset: f34dcfeecc8d Author: alanb Date: 2011-02-07 13:53 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/f34dcfeecc8d 7012823: TEST_BUG: java/nio/MappedByteBuffer tests leave file mappingsthat prevent clean-up (win) Reviewed-by: forax ! test/java/nio/MappedByteBuffer/Force.java ! test/java/nio/MappedByteBuffer/ZeroMap.java Changeset: 32f1c5f67aae Author: alanb Date: 2011-02-07 13:55 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/32f1c5f67aae 7003155: (fs) Paths.get() does not handle escaped octets correctly Reviewed-by: sherman ! src/solaris/classes/sun/nio/fs/UnixUriUtils.java ! test/java/nio/file/Path/UriImportExport.java Changeset: 94bcd9aa2119 Author: chegar Date: 2011-02-07 14:08 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/94bcd9aa2119 7016898: PlainSocketImpl.fd is null on Windows Reviewed-by: alanb ! src/windows/classes/java/net/PlainSocketImpl.java Changeset: f9f321a7502c Author: alanb Date: 2011-02-07 18:01 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/f9f321a7502c 7017454: Residual warnings in sun/nio/** and java/io native code (win64) Reviewed-by: chegar ! src/share/native/java/io/io_util.c ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/canonicalize_md.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/sun/nio/ch/Iocp.c ! src/windows/native/sun/nio/fs/RegistryFileTypeDetector.c ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c Changeset: 08e1914d5852 Author: alanb Date: 2011-02-07 18:02 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/08e1914d5852 Merge Changeset: 947ce00ed7a2 Author: alanb Date: 2011-02-08 15:50 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/947ce00ed7a2 7013585: Dual-pivot quicksort improvements for highly structured (nearly sorted) and data with small periods Reviewed-by: mduigou, alanb Contributed-by: vladimir.yaroslavskiy at oracle.com ! src/share/classes/java/util/DualPivotQuicksort.java ! test/java/util/Arrays/Sorting.java Changeset: 82c8c54ac1d5 Author: alanb Date: 2011-02-08 19:31 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/82c8c54ac1d5 4421494: infinite loop while parsing double literal Reviewed-by: darcy, alanb Contributed-by: dmitry.nadezhin at oracle.com ! src/share/classes/sun/misc/FloatingDecimal.java ! test/java/lang/Double/ParseDouble.java Changeset: 6661a1dfa369 Author: sherman Date: 2011-02-08 13:30 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/6661a1dfa369 7017840: (zipfs) test/demo/zipfs/basic.sh needs to be updated due to 7013420 Summary: updated try-with-resourcse usage in test/demo code Reviewed-by: alanb ! src/share/demo/nio/zipfs/Demo.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh Changeset: 1899523d8f24 Author: lana Date: 2011-02-08 14:25 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/1899523d8f24 Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: cd9a302f2806 Author: chegar Date: 2011-02-09 09:53 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/cd9a302f2806 7013961: Threads attached via JNI attach prevent daemon ThreadGroups from being destroyed Reviewed-by: dholmes ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java Changeset: 6a274c4d3e00 Author: alanb Date: 2011-02-09 15:59 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/6a274c4d3e00 7018258: Dual-pivot updates in 7013585 can fail with ArrayIndexOutOfBoundsException Reviewed-by: alanb Contributed-by: vladimir.yaroslavskiy at oracle.com ! src/share/classes/java/util/DualPivotQuicksort.java ! test/java/util/Arrays/Sorting.java Changeset: 37563c09305d Author: alanb Date: 2011-02-09 16:30 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/37563c09305d Merge Changeset: a8fcaf5097ec Author: lana Date: 2011-02-09 10:28 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/a8fcaf5097ec Merge Changeset: 9d141e45ee4b Author: lana Date: 2011-02-14 16:30 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/9d141e45ee4b Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: e4802c87e5c7 Author: herrick Date: 2011-02-09 09:19 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/e4802c87e5c7 7016724: Remove sun.jkernel.* classes in JDK 7 Summary: Remove sun.jkernel.* classes in JDK 7 Reviewed-by: ohair, alanb, mchung ! make/modules/modules.config ! make/sun/Makefile - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/util/zip/ZipEntry.java - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java ! src/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java ! src/share/classes/sun/misc/BootClassLoaderHook.java ! src/share/classes/sun/tools/attach/HotSpotAttachProvider.java ! src/windows/bin/java_md.c - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc Changeset: dc909d130397 Author: herrick Date: 2011-02-09 09:32 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/dc909d130397 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 4f84cda2a7d5 Author: igor Date: 2011-02-09 21:20 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/4f84cda2a7d5 Merge - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc Changeset: 802c085308bf Author: igor Date: 2011-02-15 19:16 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/802c085308bf Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: 7bb09178ffc7 Author: ohair Date: 2011-02-10 20:45 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/7bb09178ffc7 7012644: Regression: jdk/make/common/shared/Defs-windows.gmk has problems on cygwin 7018835: Debug build issues in jdk makefiles Reviewed-by: ksrini ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Platform.gmk Changeset: 9478964f9425 Author: ohair Date: 2011-02-10 20:51 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/9478964f9425 Merge Changeset: 71b52ce5f389 Author: mfang Date: 2011-02-10 20:52 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/71b52ce5f389 7017734: jdk7 message drop 1 translation integration Reviewed-by: ogino, yhuang ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ja.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ko.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_CN.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_es.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_it.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ja.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ko.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_sv.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_es.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_fr.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ja.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_sv.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_es.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_fr.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_it.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_sv.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_de.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_es.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_it.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_de.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_es.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_it.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties ! src/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties ! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_es.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_fr.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_it.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ja.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ko.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_sv.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_TW.java ! src/share/classes/sun/awt/resources/awt_de.properties ! src/share/classes/sun/awt/resources/awt_es.properties ! src/share/classes/sun/awt/resources/awt_fr.properties ! src/share/classes/sun/awt/resources/awt_it.properties ! src/share/classes/sun/awt/resources/awt_ja.properties ! src/share/classes/sun/awt/resources/awt_ko.properties ! src/share/classes/sun/awt/resources/awt_pt_BR.properties ! src/share/classes/sun/awt/resources/awt_sv.properties ! src/share/classes/sun/awt/resources/awt_zh_CN.properties ! src/share/classes/sun/awt/resources/awt_zh_TW.properties ! src/share/classes/sun/management/resources/agent_de.properties ! src/share/classes/sun/management/resources/agent_es.properties ! src/share/classes/sun/management/resources/agent_fr.properties ! src/share/classes/sun/management/resources/agent_it.properties ! src/share/classes/sun/management/resources/agent_ja.properties ! src/share/classes/sun/management/resources/agent_ko.properties ! src/share/classes/sun/management/resources/agent_pt_BR.properties ! src/share/classes/sun/management/resources/agent_sv.properties ! src/share/classes/sun/management/resources/agent_zh_CN.properties ! src/share/classes/sun/management/resources/agent_zh_TW.properties ! src/share/classes/sun/misc/resources/Messages_de.java ! src/share/classes/sun/misc/resources/Messages_es.java ! src/share/classes/sun/misc/resources/Messages_fr.java ! src/share/classes/sun/misc/resources/Messages_it.java ! src/share/classes/sun/misc/resources/Messages_ja.java ! src/share/classes/sun/misc/resources/Messages_ko.java ! src/share/classes/sun/misc/resources/Messages_pt_BR.java ! src/share/classes/sun/misc/resources/Messages_sv.java ! src/share/classes/sun/misc/resources/Messages_zh_CN.java ! src/share/classes/sun/misc/resources/Messages_zh_TW.java ! src/share/classes/sun/print/resources/serviceui_de.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_ja.properties ! src/share/classes/sun/print/resources/serviceui_ko.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/print/resources/serviceui_zh_CN.properties ! src/share/classes/sun/print/resources/serviceui_zh_TW.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_es.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_fr.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_it.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ja.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ko.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_sv.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_CN.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_TW.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_ja.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_de.properties ! src/share/classes/sun/rmi/server/resources/rmid_es.properties ! src/share/classes/sun/rmi/server/resources/rmid_fr.properties ! src/share/classes/sun/rmi/server/resources/rmid_it.properties ! src/share/classes/sun/rmi/server/resources/rmid_ja.properties ! src/share/classes/sun/rmi/server/resources/rmid_ko.properties ! src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties ! src/share/classes/sun/rmi/server/resources/rmid_sv.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_TW.properties ! src/share/classes/sun/security/tools/JarSignerResources_ja.java ! src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_de.java ! src/share/classes/sun/security/util/AuthResources_es.java ! src/share/classes/sun/security/util/AuthResources_fr.java ! src/share/classes/sun/security/util/AuthResources_it.java ! src/share/classes/sun/security/util/AuthResources_ja.java ! src/share/classes/sun/security/util/AuthResources_ko.java ! src/share/classes/sun/security/util/AuthResources_pt_BR.java ! src/share/classes/sun/security/util/AuthResources_sv.java ! src/share/classes/sun/security/util/AuthResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_zh_TW.java ! src/share/classes/sun/security/util/Resources_de.java ! src/share/classes/sun/security/util/Resources_es.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java ! src/share/classes/sun/security/util/Resources_ja.java ! src/share/classes/sun/security/util/Resources_ko.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/security/util/Resources_sv.java ! src/share/classes/sun/security/util/Resources_zh_CN.java ! src/share/classes/sun/security/util/Resources_zh_TW.java ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/share/classes/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_ja.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_zh_CN.java ! src/share/classes/sun/tools/serialver/serialver_ja.properties ! src/share/classes/sun/tools/serialver/serialver_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_de.properties ! src/share/classes/sun/util/logging/resources/logging_es.properties ! src/share/classes/sun/util/logging/resources/logging_fr.properties ! src/share/classes/sun/util/logging/resources/logging_it.properties ! src/share/classes/sun/util/logging/resources/logging_ja.properties ! src/share/classes/sun/util/logging/resources/logging_ko.properties ! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties ! src/share/classes/sun/util/logging/resources/logging_sv.properties ! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties ! src/share/demo/jfc/CodePointIM/resources/codepoint_ja.properties ! src/share/demo/jfc/CodePointIM/resources/codepoint_zh_CN.properties ! src/share/demo/jfc/Font2DTest/resources/TextResources_ja.properties ! src/share/demo/jfc/Font2DTest/resources/TextResources_zh_CN.properties ! src/share/demo/jfc/Notepad/resources/Notepad_ja.properties ! src/share/demo/jfc/Notepad/resources/Notepad_zh_CN.properties ! src/windows/classes/sun/awt/windows/awtLocalization_es.properties ! src/windows/classes/sun/awt/windows/awtLocalization_ja.properties ! src/windows/classes/sun/awt/windows/awtLocalization_ko.properties ! src/windows/classes/sun/awt/windows/awtLocalization_pt_BR.properties ! src/windows/classes/sun/awt/windows/awtLocalization_zh_CN.properties ! src/windows/classes/sun/awt/windows/awtLocalization_zh_TW.properties ! src/windows/native/sun/jkernel/kernel_de.rc ! src/windows/native/sun/jkernel/kernel_es.rc ! src/windows/native/sun/jkernel/kernel_fr.rc ! src/windows/native/sun/jkernel/kernel_it.rc ! src/windows/native/sun/jkernel/kernel_ja.rc ! src/windows/native/sun/jkernel/kernel_ko.rc ! src/windows/native/sun/jkernel/kernel_pt_BR.rc ! src/windows/native/sun/jkernel/kernel_sv.rc ! src/windows/native/sun/jkernel/kernel_zh.rc ! src/windows/native/sun/jkernel/kernel_zh_TW.rc Changeset: 8b6d1d96ef3d Author: mfang Date: 2011-02-11 22:57 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/8b6d1d96ef3d Merge Changeset: 0eacbbc8e1fb Author: mfang Date: 2011-02-11 23:46 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/0eacbbc8e1fb Merge Changeset: 780e53ad2896 Author: mfang Date: 2011-02-14 13:01 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/780e53ad2896 Merge Changeset: 5fab973e5a47 Author: ohair Date: 2011-02-15 12:34 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/5fab973e5a47 Merge Changeset: bdc069d3f910 Author: ohair Date: 2011-02-15 20:18 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/bdc069d3f910 Merge Changeset: 89055b6d9ae0 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/89055b6d9ae0 Added tag jdk7-b130 for changeset bdc069d3f910 ! .hgtags Changeset: 0355c60c2da4 Author: ohair Date: 2011-02-16 13:29 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/0355c60c2da4 7013964: openjdk LICENSE file needs rebranding Reviewed-by: darcy, katleman, jjg ! LICENSE Changeset: 9b2631288894 Author: ohair Date: 2011-02-16 14:33 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/9b2631288894 7010594: Add /SAFESEH to links on windows to verify safe exceptions Reviewed-by: alanb ! make/common/Defs-windows.gmk ! make/common/shared/Defs-windows.gmk Changeset: 5e09deee1967 Author: andrew Date: 2011-02-23 17:10 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/5e09deee1967 7021314: Build should not install javaws man page Summary: Only install javaws.1 when not building OpenJDK Reviewed-by: alanb, ohair ! make/common/Release.gmk Changeset: 8ac52c85f9e9 Author: cl Date: 2011-02-23 15:49 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/8ac52c85f9e9 Merge Changeset: 11c9a066a5a4 Author: cl Date: 2011-02-24 15:16 -0800 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/11c9a066a5a4 Added tag jdk7-b131 for changeset 8ac52c85f9e9 ! .hgtags Changeset: 6b160a0efd3b Author: mcimadamore Date: 2011-03-01 16:36 +0000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/6b160a0efd3b merge with jdk7-b131 - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile ! src/share/bin/java.c - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/share/demo/zipfs - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java - test/sun/security/krb5/auto/basic.sh Changeset: e81f4d7f95f8 Author: briangoetz Date: 2011-03-10 18:43 -0500 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/e81f4d7f95f8 Merge ! make/common/shared/Defs-control.gmk ! make/common/shared/Defs-java.gmk - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile ! make/java/java/FILES_java.gmk - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/share/demo/zipfs - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java - test/sun/security/krb5/auto/basic.sh From reinier at zwitserloot.com Sat Mar 12 10:36:48 2011 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Sat, 12 Mar 2011 19:36:48 +0100 Subject: Is there a list of (defender) additions to the collections anywhere? Message-ID: I assume this list would contain map, filter, fold, etc. --Reinier Zwitserloot From reinier at zwitserloot.com Sat Mar 12 14:01:44 2011 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Sat, 12 Mar 2011 23:01:44 +0100 Subject: Design for collections upgrades In-Reply-To: <002701cbdf2e$0e98dda0$2bca98e0$@com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <002701cbdf2e$0e98dda0$2bca98e0$@com> Message-ID: >From personal experience, students are completely bewildered that someList.map(someClosure) has absolutely nothing at all to do with maps (in the java.util.Map sense). 'transform' is a better name. I'm not sure which SQL term is a good fit for map. "select" doesn't really seem to cover it, though I'm guessing that's what Llewellyn intended. Immutable maps are not part of java's type system (at least, rt.jar). Java's type system leans heavily towards mutable collections (i.e. the basic Map, Set, Collection and List include mutating methods, and none of them have methods that return new collection instances based on old instances. For example, no such interface has an 'append' method, or a not-in-place retainAll/removeAll). Thus, as Stephen Colebourne said, consistency says that these methods should run in-place, even if that doesn't fit the expectation of those who are used to functional programming. It wouldn't make any sense for List to have NO .append() method, which returns a new list containing the same elements as this list plus a new element added at the end, while it DOES have a .filter() method which returns a new list containing all elements that pass the supplied filter closure. This does mean that i.e. .transform() HAS to transform from one type to the same type. .filter() is easily named: retainAll and removeAll are already in the API and need merely be overloaded with the signature that takes a closure instead of another collection. Just like retain and remove, these would definitely be in-place. That leaves 'filter' free for some future immutable collection API that returns a new instance. .map() / .transform() is the true problem here: Not only is naming this one difficult, its also annoying to do in-place, as an in-place transform requires the mapping to go from ? super E to ? extends E; you can't map from String to Integer with such a construct. Nevertheless, including a non-in-place version of transform() as a defender method just doesn't feel consistent, but adding the full set of immutable 'mutators' (append, prepend, a non-in-place take on removeAll/retainAll/addAll, a non-in-place variant of removeAll/retainAll, in-place transform and non-in-place transform, and more) - that's a huge undertaking and adds a large bunch of new methods to the collections API, all of which has to be written with defender methods so as to stay backwards compatible, and they all suffer from the issue of not returning the same type of collection as the starting type. For some types this is irrelevant, but i.e. a LinkedHashMap returning a plain HashMap is definitely sub-optimal. Letting each collection type use i.e. .newInstance() to help with this also doesn't sound like a good idea; for starters not every conceivable subclass of Map/List/etc can be effectively cloned by re-filling it in the same order as its iterator() method supplies values, and it would create a large timespan in which some collections do return 'Self' for .newInstance(), but others fall back on HashMap. If this idea is persued, .clone() or more likely a newly introduced and defenderized .copy() should be used instead of .newInstance(). Thus, I don't think adding non-in-place versions of anything is a feasible idea for the existing Collections API; there are far too many issues. Instead, I suggest (perhaps for JDK8) an entirely new type tree is made for immutable collections, including the complete set of immutable not-in-place versions of retain/remove/appendAll/append/prepend/etc. As it would be new API none of these methods would need to be defender methods and thus each implementation can be responsible for returning the appropriate type. In the mean time, a utility method in Collections which filters / transforms existing collections into a new collection of a preset known type (HashSet, ArrayList, and LinkedHashMap seem like the most obvious choices here) can be added to at least let programmers do a String->Integer mapping using just the classes in JDK7's rt.jar. Such a method would have to be named appropriately to minimize confusion (as Collections.sort() would do an in-place sort, but Collections.transform() would produce a new ArrayList, for example. Possibly a new utility class needs to be created to separate these two modes. --Reinier Zwitserloot On Thu, Mar 10, 2011 at 3:18 PM, Seamus Sullivan wrote: > Regarding 'map' - this should be a very frequently used method; it seems > likely that there will be a bit of confusion between the interface and the > method in discussions. I would suggest using C++'s standard template library > name for the similar function: 'transform' to avoid conflating the two. > > Regarding altering the original collection: this seems like a bad idea. > From my experience using the STL's remove functions, I had to frequently > make temporary copies of collections prior to filtering (remove_if) so that > collections wouldn't be altered for further/different processing at later > stages. Yes, after a while I should have caught on and created my own > versions of remove_* that did just that. > > Seamus > > -----Original Message----- > From: lambda-dev-bounces at openjdk.java.net [mailto: > lambda-dev-bounces at openjdk.java.net] On Behalf Of Stephen Colebourne > Sent: Thursday, March 10, 2011 6:58 AM > To: lambda-dev > Subject: Re: Design for collections upgrades > > The point I was trying to make is that to me the method name "filter" > means filter this collection in place, not return a new copy that is > filtered. Just like Collections.sort, shuffle or swap. Its the active > tense that implies it. > > I also think that Java is a mutation based language in developers > minds, and if you asked around then that in-place change is what would > be expected. Now, the FP viewpoint suggests thats a bad idea, and the > presence of immutable collections makes it hard to implement, but that > doesn't change what I perceive developers would currently expect from > that method name and similar actve tense ones. > > Finally, I'd argue against using "map" as a method name in Java, given > the strong connection to the entirely different concept of the Map > interface. > > Stephen > > > 2011/3/10 "Zden?k Tron??ek" : > > To me it seems logical that filter() returns the same collection as was > > the original collection. For Set you do not have any other choice either: > > > > set.filter(predicate) > > > > cannot switch from HashSet to TreeSet or back. > > > > Z. > > -- > > Zdenek Tronicek > > FIT CTU in Prague > > > > > > R?mi Forax napsal(a): > >> > >> List things = ... > >> Collection fooAbles = things.filter(#Thing.isFoo); // ooh, > >> pretty > >> > >> > >> Not that pretty because filter have to create a new collection and > >> there is no way to do that apart hard coding a new ArrayList somewhere. > >> > >> It's better in my opinion to have a filterTo that takes a collection > >> as argument. > >> > >> Collection fooAbles = things.filterTo(#Thing.isFoo, new > >> HashSet<>()); > >> > >> > >> R?mi > >> > >> On 03/08/2011 06:23 PM, Brian Goetz wrote: > >>> Since people are already discussing this based on an experimental > >>> checkin, let me outline the big picture plan here. > >>> > >>> The general idea is to add functional-like operations to collections -- > >>> filter, map, reduce, apply. > >>> > >>> I see three sensible modes, with explicit choices of which you get. > >>> > >>> 1. Serial / Eager. This is the straight > >>> collections-with-functional-style mode, and some samples have already > >>> been checked in as proof of concept. Operations on collections yield > >>> new collections, and you can chain the calls. It values ease of use > >>> over performance (no new concepts like laziness), but the performance > >>> model is still highly predictable. You get things like > >>> > >>> Collection fooAbles = things.filter( #{ t -> t.isFoo() }); > >>> > >>> or, with method references: > >>> > >>> Collection fooAbles = things.filter(#Thing.isFoo); // ooh, > pretty > >>> > >>> You can also chain calls together, though you pay a (predictable) > >>> performance cost of intermediate collections, which for small > >>> collections is unlikely to matter: > >>> > >>> maxFooWeight = things.filter(#Thing.isFoo) > >>> .map(#Thing.getWeight) > >>> .max(); > >>> > >>> The benefit here is concision and clarity. The cost is some > >>> performance, but maybe not so much that people freak out. If people > >>> care, they move to the next model, which is: > >>> > >>> 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be > >>> chosen later, Remi used "lazy" in his example.) To transfer between > >>> "eager world" and "lazy world", you use conversion methods (toStream / > >>> toCollection). A typical call chain probably looks like: > >>> collection.toStream / op / op / op / {toCollection,reduce,apply} > >>> > >>> so the above example becomes > >>> > >>> maxFooWeight = things.asStream() > >>> .filter(#Thing.isFoo) > >>> .map(#Thing.getWeight) > >>> .max(); > >>> > >>> The return type of Collection.filter is different from the return type > >>> of Stream.filter, so the choice and performance costs are reflected in > >>> the static type system. This avoids the cost of the intermediate > >>> collections, but is still serial. If you care about that, you move up > >>> to the next model, which is: > >>> > >>> 3. Parallel / Lazy. Here, the primary abstraction is something like > >>> ParallelStream or ParallelIterable. Let's call it ParallelFoo to avoid > >>> bikeshedding for the moment. Now, the code looks like: > >>> > >>> maxFooWeight = things.asParallelFoo() > >>> .filter(#Thing.isFoo) > >>> .map(#Thing.getWeight) > >>> .max(); > >>> > >>> Again, the return type of ParallelFoo.filter is different from > >>> Stream.filter or Collection.filter, so again the choice is reflected in > >>> the static type system. But you don't have to rewrite your code. > >>> > >>> The beauty here is twofold: > >>> > >>> - The base model (serial/eager) is easy to understand and natural to > >>> use as a way of expressing what the programmer wants to do, and > >>> attractive enough to stand on its own -- just a little slow with big > >>> collections. > >>> - Switching between execution models is mostly a matter of adding an > >>> explicit conversion or two in the call chain, as the models are similar > >>> enough that the rest of the code should still work (and even mean the > >>> same thing.) > >>> > >>> > >>> On 3/8/2011 8:43 AM, R?mi Forax wrote: > >>>> Le 08/03/2011 14:31, Jim Mayer a ?crit : > >>>>> // I can tolerate this one > >>>>> long product(List list) { > >>>>> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> > >>>>> sum * x}); > >>>>> } > >>>> I prefer this one: > >>>> > >>>> long product(List list) { > >>>> return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, > >>>> x -> sum * x}); > >>>> } > >>>> > >>>> lazy() means, don't do map directly, but wait and do map and reduce in > >>>> one iteration. > >>>> > >>>> R?mi > >>>> > >>>> > >> > >> > >> > > > > > > > > > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon this information by persons or > entities other than the intended recipient is prohibited. If you received > this in error, please contact the sender and delete the material from any > computer. > > From forax at univ-mlv.fr Sat Mar 12 15:27:17 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Sun, 13 Mar 2011 00:27:17 +0100 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <002701cbdf2e$0e98dda0$2bca98e0$@com> Message-ID: <4D7C0155.30304@univ-mlv.fr> On 03/12/2011 11:01 PM, Reinier Zwitserloot wrote: > From personal experience, students are completely bewildered that > someList.map(someClosure) has absolutely nothing at all to do with maps (in > the java.util.Map sense). 'transform' is a better name. I'm not sure which > SQL term is a good fit for map. "select" doesn't really seem to cover it, > though I'm guessing that's what Llewellyn intended. 'map' means association. Map stores associations, map apply an association function, so they are related. > Immutable maps are not part of java's type system (at least, rt.jar). Java's > type system leans heavily towards mutable collections (i.e. the basic Map, > Set, Collection and List include mutating methods, and none of them have > methods that return new collection instances based on old instances. For > example, no such interface has an 'append' method, or a not-in-place > retainAll/removeAll). Yes. > Thus, as Stephen Colebourne said, consistency says that these methods should > run in-place, even if that doesn't fit the expectation of those who are used > to functional programming. It wouldn't make any sense for List to have NO > .append() method, which returns a new list containing the same elements as > this list plus a new element added at the end, while it DOES have a > .filter() method which returns a new list containing all elements that pass > the supplied filter closure. This does mean that i.e. .transform() HAS to > transform from one type to the same type. > > .filter() is easily named: retainAll and removeAll are already in the API > and need merely be overloaded with the signature that takes a closure > instead of another collection. Just like retain and remove, these would > definitely be in-place. That leaves 'filter' free for some future immutable > collection API that returns a new instance. I agree. We have to provide mutable version of of map/filter. > .map() / .transform() is the true problem here: Not only is naming this one > difficult, its also annoying to do in-place, as an in-place transform > requires the mapping to go from ? super E to ? extends E; you can't map from > String to Integer with such a construct. Nevertheless, including a > non-in-place version of transform() as a defender method just doesn't feel > consistent, but adding the full set of immutable 'mutators' (append, > prepend, a non-in-place take on removeAll/retainAll/addAll, a non-in-place > variant of removeAll/retainAll, in-place transform and non-in-place > transform, and more) - that's a huge undertaking and adds a large bunch of > new methods to the collections API, all of which has to be written with > defender methods so as to stay backwards compatible, and they all suffer > from the issue of not returning the same type of collection as the starting > type. For some types this is irrelevant, but i.e. a LinkedHashMap returning > a plain HashMap is definitely sub-optimal. Letting each collection type use > i.e. .newInstance() to help with this also doesn't sound like a good idea; > for starters not every conceivable subclass of Map/List/etc can be > effectively cloned by re-filling it in the same order as its iterator() > method supplies values, and it would create a large timespan in which some > collections do return 'Self' for .newInstance(), but others fall back on > HashMap. If this idea is persued, .clone() or more likely a newly introduced > and defenderized .copy() should be used instead of .newInstance(). You forget the golden trick :) We don't do lazy filter on the collection itself but on the stream created from the collection. collection.asStream().filter(...) asStream() is here to say, I don't want to consider the collection as a mutable collection but as an sequence of elements. And filter or map will return a new stream. > Thus, I don't think adding non-in-place versions of anything is a feasible > idea for the existing Collections API; there are far too many issues. > > Instead, I suggest (perhaps for JDK8) an entirely new type tree is made for > immutable collections, including the complete set of immutable not-in-place > versions of retain/remove/appendAll/append/prepend/etc. As it would be new > API none of these methods would need to be defender methods and thus each > implementation can be responsible for returning the appropriate type. > > In the mean time, a utility method in Collections which filters / transforms > existing collections into a new collection of a preset known type (HashSet, > ArrayList, and LinkedHashMap seem like the most obvious choices here) can be > added to at least let programmers do a String->Integer mapping using just > the classes in JDK7's rt.jar. Such a method would have to be named > appropriately to minimize confusion (as Collections.sort() would do an > in-place sort, but Collections.transform() would produce a new ArrayList, > for example. Possibly a new utility class needs to be created to separate > these two modes. > > --Reinier Zwitserloot R?mi From int19h at gmail.com Sat Mar 12 17:30:58 2011 From: int19h at gmail.com (Pavel Minaev) Date: Sat, 12 Mar 2011 17:30:58 -0800 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: <4D7665FB.5070209@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: I've been re-reading the "Design for collection upgrades" thread, and had some thoughts on the nature of the Stream abstraction (for lazy/serial scenario) as originally outlined in Brian's post that kicked off the thread, and users expectations of what comes with that name. Per the proposal, it sounds like Stream is more or less a marker interface to indicate lazy operations, and not otherwise any different from Iterable. However, this isn't what "stream" has historically meant in imperative PLs and their frameworks. For some examples of what I mean, let me point at java.io.InputStream, or at C++ std::basic_istream. In both cases, the fundamental property of the streams - the one that is guaranteed to be supported by _any_ stream - is that you can read elements. InputStream also offers mark()/reset(), but those are conditionally supported, and so are not part of the basic contract of the abstraction; they could (one could even argue that, from a pure OOD approach, they should) just as well be moved to a more concrete interface that could be queried by clients instead of using markSupported(). The important thing with that basic contract is that once a value is read from a stream, it stays read: a stream by itself is a read-once sequence. There may be ways to obtain another stream that would re-read the same exact elements, but that would still be a new stream object. For streams that wrap some data store (e.g. FileInputStream or ByteArrayInputStream), the stream object is essentially a cursor into the store - it has a current position, which every read advances towards the end of the store. Furthermore, the stream is not _the_ store - you can have several FileInputStreams over the same file, or several ByteArrayInputStreams sharing the same byte array. Now if we take the above and see how it applies to collections, it actually is a very familiar concept: something that is not a collection itself, but is a forward-only cursor for a collection, and each collection may have more than one such cursor - why, that is Iterator. Its next() and hasNext() methods match exactly the basic input stream contract; remove() does not, but it is conditionally-supported anyway. An analogy to highlight this point: Iterator is to Iterable/Collection what ByteArrayInputStream is to byte array. Iterators, being cursors, are also naturally expected to be lazy by API clients - if I provide a method that takes an iterator, applies a filter to it, and returns another iterator as a result, no-one would expect filtering to occur over the entire collection right there and then. It's clear that the result of such operation is a "filtered iterator", that would apply the filter as it is being iterated. So, then, why not put lazy map/filter/reduce/... on Iterator? Thus, Brian's original serial/lazy example would become: maxFooWeight = things.iterator() .filter(#Thing.isFoo) .map(#Thing.getWeight) .max(); or maybe with some less concise but more descriptive (and - purely subjectively - "Java-like") names: maxFooWeight = things.iterator() .withFilter(#Thing.isFoo) .withTransform(#Thing.getWeight) .getLargestValue(); This has a nice property of working with a more fundamental abstraction than collections - I can write an Iterator that wraps a non-rewindable I/O InputStream, but I cannot write such an Iterable (well, I can - if it throws after the first call to iterator() - but it will only be usable with APIs which specify that they only call iterator() on the provided Iterable once as part of their public contract; otherwise, I'm relying on an implementation detail). The only major annoyance I can see with this approach is that enhanced-for-loop only supports Iterables (and arrays) but not Iterators, and so you'd have to write a manual loop with next()/hasNext() to iterate over the result. But is there any reason why enhanced-for cannot be made to support Iterators directly? The only thing it does to the provided Iterable is to call iterator() on it, and it does it exactly once; it would just need to use the provided Iterator directly instead. It sounds like it would be trivial to add. The above didn't touch on what the design would look like for eager or lazy/parallel operations. For parallel, the original design can be trivially adapted by moving asParallel() to Iterator directly, and producing some sort of ParallelIterator, which is simply a marker interface to enable parallelization for all applied operations, but otherwise is the same as Iterator (probably just extending it). For eager operations, I would prefer in-place mutating methods returning the receiver (to permit chaining), with distinct but obviously mapped names. For example, if Iterator has withFilter(), then Collection would have filter(). I don't think there is much utility in having eager ops that do a copy, and even less so for chaining such. I think a simple addition of something like clone() to Collection (default implementation could do newInstance() assuming a no-arg constructor available, and then addAll(this) on that new instance) would cover vast majority of all cases where you want to get a copy: the usual pattern would then be to do something like: Collection getWeights() { return things.clone().filter(#Thing.isFoo). transform(#Thing.getWeight); } where both filter() and map() operate in-place on the cloned collection. This also skirts the whole question of the type of the resulting collection produced by a copying operation - it's clear and unambiguous what it'll be for clone(), and no other operation makes a copy. On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz wrote: > Since people are already discussing this based on an experimental > checkin, let me outline the big picture plan here. > > The general idea is to add functional-like operations to collections -- > filter, map, reduce, apply. > > I see three sensible modes, with explicit choices of which you get. > > 1. Serial / Eager. This is the straight > collections-with-functional-style mode, and some samples have already > been checked in as proof of concept. Operations on collections yield > new collections, and you can chain the calls. It values ease of use > over performance (no new concepts like laziness), but the performance > model is still highly predictable. You get things like > > Collection fooAbles = things.filter( #{ t -> t.isFoo() }); > > or, with method references: > > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty > > You can also chain calls together, though you pay a (predictable) > performance cost of intermediate collections, which for small > collections is unlikely to matter: > > maxFooWeight = things.filter(#Thing.isFoo) > .map(#Thing.getWeight) > .max(); > > The benefit here is concision and clarity. The cost is some > performance, but maybe not so much that people freak out. If people > care, they move to the next model, which is: > > 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be > chosen later, Remi used "lazy" in his example.) To transfer between > "eager world" and "lazy world", you use conversion methods (toStream / > toCollection). A typical call chain probably looks like: > collection.toStream / op / op / op / {toCollection,reduce,apply} > > so the above example becomes > > maxFooWeight = things.asStream() > .filter(#Thing.isFoo) > .map(#Thing.getWeight) > .max(); > > The return type of Collection.filter is different from the return type > of Stream.filter, so the choice and performance costs are reflected in > the static type system. This avoids the cost of the intermediate > collections, but is still serial. If you care about that, you move up > to the next model, which is: > > 3. Parallel / Lazy. Here, the primary abstraction is something like > ParallelStream or ParallelIterable. Let's call it ParallelFoo to avoid > bikeshedding for the moment. Now, the code looks like: > > maxFooWeight = things.asParallelFoo() > .filter(#Thing.isFoo) > .map(#Thing.getWeight) > .max(); > > Again, the return type of ParallelFoo.filter is different from > Stream.filter or Collection.filter, so again the choice is reflected in > the static type system. But you don't have to rewrite your code. > > The beauty here is twofold: > > - The base model (serial/eager) is easy to understand and natural to > use as a way of expressing what the programmer wants to do, and > attractive enough to stand on its own -- just a little slow with big > collections. > - Switching between execution models is mostly a matter of adding an > explicit conversion or two in the call chain, as the models are similar > enough that the rest of the code should still work (and even mean the > same thing.) > > > On 3/8/2011 8:43 AM, R?mi Forax wrote: > > Le 08/03/2011 14:31, Jim Mayer a ?crit : > >> // I can tolerate this one > >> long product(List list) { > >> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> sum > * x}); > >> } > > > > I prefer this one: > > > > long product(List list) { > > return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, x -> > sum * x}); > > } > > > > lazy() means, don't do map directly, but wait and do map and reduce in > > one iteration. > > > > R?mi > > > > > > From robert.field at oracle.com Sat Mar 12 17:46:01 2011 From: robert.field at oracle.com (robert.field at oracle.com) Date: Sun, 13 Mar 2011 01:46:01 +0000 Subject: hg: lambda/defender-prototype: Merge in Brian's batch jdk weaver; Change agent to be more version compatible Message-ID: <20110313014602.474E8470EA@hg.openjdk.java.net> Changeset: 6332c5f2d589 Author: Robert Field Date: 2011-03-12 17:46 -0800 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/6332c5f2d589 Merge in Brian's batch jdk weaver; Change agent to be more version compatible ! build.xml ! src/jsr335/agent/remi/ClassMirror.java From cgdecker at gmail.com Sat Mar 12 19:53:57 2011 From: cgdecker at gmail.com (Colin Decker) Date: Sat, 12 Mar 2011 22:53:57 -0500 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: I don't feel like a comparison to InputStream etc. makes much sense considering "Stream" is an arbitrary name that can easily be changed to something more appropriate ("Streamable", say). I also think it's a weakness of the IO streams that they don't have an Iterable equivalent (like InputSupplier from Guava). Regardless, limiting lazy filter/map to Iterator would be... undesirable. I do think Iterator should have such methods as well, though. -- Colin On Sat, Mar 12, 2011 at 8:30 PM, Pavel Minaev wrote: > I've been re-reading the "Design for collection upgrades" thread, and had > some thoughts on the nature of the Stream abstraction (for lazy/serial > scenario) as originally outlined in Brian's post that kicked off the > thread, > and users expectations of what comes with that name. > > Per the proposal, it sounds like Stream is more or less a marker interface > to indicate lazy operations, and not otherwise any different from Iterable. > However, this isn't what "stream" has historically meant in imperative PLs > and their frameworks. For some examples of what I mean, let me point at > java.io.InputStream, or at C++ std::basic_istream. In both cases, the > fundamental property of the streams - the one that is guaranteed to be > supported by _any_ stream - is that you can read elements. InputStream also > offers mark()/reset(), but those are conditionally supported, and so are > not > part of the basic contract of the abstraction; they could (one could even > argue that, from a pure OOD approach, they should) just as well be moved to > a more concrete interface that could be queried by clients instead of using > markSupported(). > > The important thing with that basic contract is that once a value is read > from a stream, it stays read: a stream by itself is a read-once sequence. > There may be ways to obtain another stream that would re-read the same > exact > elements, but that would still be a new stream object. For streams that > wrap > some data store (e.g. FileInputStream or ByteArrayInputStream), the stream > object is essentially a cursor into the store - it has a current position, > which every read advances towards the end of the store. Furthermore, the > stream is not _the_ store - you can have several FileInputStreams over the > same file, or several ByteArrayInputStreams sharing the same byte array. > > Now if we take the above and see how it applies to collections, it actually > is a very familiar concept: something that is not a collection itself, but > is a forward-only cursor for a collection, and each collection may have > more > than one such cursor - why, that is Iterator. Its next() and hasNext() > methods match exactly the basic input stream contract; remove() does not, > but it is conditionally-supported anyway. An analogy to highlight this > point: Iterator is to Iterable/Collection what ByteArrayInputStream is to > byte array. > > Iterators, being cursors, are also naturally expected to be lazy by API > clients - if I provide a method that takes an iterator, applies a filter to > it, and returns another iterator as a result, no-one would expect filtering > to occur over the entire collection right there and then. It's clear that > the result of such operation is a "filtered iterator", that would apply the > filter as it is being iterated. > > So, then, why not put lazy map/filter/reduce/... on Iterator? Thus, Brian's > original serial/lazy example would become: > > maxFooWeight = things.iterator() > .filter(#Thing.isFoo) > .map(#Thing.getWeight) > .max(); > > or maybe with some less concise but more descriptive (and - purely > subjectively - "Java-like") names: > > maxFooWeight = things.iterator() > .withFilter(#Thing.isFoo) > .withTransform(#Thing.getWeight) > .getLargestValue(); > > This has a nice property of working with a more fundamental abstraction > than > collections - I can write an Iterator that wraps a non-rewindable I/O > InputStream, but I cannot write such an Iterable (well, I can - if it > throws > after the first call to iterator() - but it will only be usable with APIs > which specify that they only call iterator() on the provided Iterable once > as part of their public contract; otherwise, I'm relying on an > implementation detail). > > The only major annoyance I can see with this approach is that > enhanced-for-loop only supports Iterables (and arrays) but not Iterators, > and so you'd have to write a manual loop with next()/hasNext() to iterate > over the result. But is there any reason why enhanced-for cannot be made to > support Iterators directly? The only thing it does to the provided Iterable > is to call iterator() on it, and it does it exactly once; it would just > need > to use the provided Iterator directly instead. It sounds like it would be > trivial to add. > > > The above didn't touch on what the design would look like for eager or > lazy/parallel operations. For parallel, the original design can be > trivially > adapted by moving asParallel() to Iterator directly, and producing some > sort > of ParallelIterator, which is simply a marker interface to enable > parallelization for all applied operations, but otherwise is the same as > Iterator (probably just extending it). > > For eager operations, I would prefer in-place mutating methods returning > the > receiver (to permit chaining), with distinct but obviously mapped names. > For > example, if Iterator has withFilter(), then Collection would have filter(). > I don't think there is much utility in having eager ops that do a copy, and > even less so for chaining such. I think a simple addition of something like > clone() to Collection (default implementation could do newInstance() > assuming a no-arg constructor available, and then addAll(this) on that new > instance) would cover vast majority of all cases where you want to get a > copy: the usual pattern would then be to do something like: > > Collection getWeights() { > return things.clone().filter(#Thing.isFoo). > transform(#Thing.getWeight); > } > > where both filter() and map() operate in-place on the cloned collection. > This also skirts the whole question of the type of the resulting collection > produced by a copying operation - it's clear and unambiguous what it'll be > for clone(), and no other operation makes a copy. > > > On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz > wrote: > > > Since people are already discussing this based on an experimental > > checkin, let me outline the big picture plan here. > > > > The general idea is to add functional-like operations to collections -- > > filter, map, reduce, apply. > > > > I see three sensible modes, with explicit choices of which you get. > > > > 1. Serial / Eager. This is the straight > > collections-with-functional-style mode, and some samples have already > > been checked in as proof of concept. Operations on collections yield > > new collections, and you can chain the calls. It values ease of use > > over performance (no new concepts like laziness), but the performance > > model is still highly predictable. You get things like > > > > Collection fooAbles = things.filter( #{ t -> t.isFoo() }); > > > > or, with method references: > > > > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty > > > > You can also chain calls together, though you pay a (predictable) > > performance cost of intermediate collections, which for small > > collections is unlikely to matter: > > > > maxFooWeight = things.filter(#Thing.isFoo) > > .map(#Thing.getWeight) > > .max(); > > > > The benefit here is concision and clarity. The cost is some > > performance, but maybe not so much that people freak out. If people > > care, they move to the next model, which is: > > > > 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be > > chosen later, Remi used "lazy" in his example.) To transfer between > > "eager world" and "lazy world", you use conversion methods (toStream / > > toCollection). A typical call chain probably looks like: > > collection.toStream / op / op / op / {toCollection,reduce,apply} > > > > so the above example becomes > > > > maxFooWeight = things.asStream() > > .filter(#Thing.isFoo) > > .map(#Thing.getWeight) > > .max(); > > > > The return type of Collection.filter is different from the return type > > of Stream.filter, so the choice and performance costs are reflected in > > the static type system. This avoids the cost of the intermediate > > collections, but is still serial. If you care about that, you move up > > to the next model, which is: > > > > 3. Parallel / Lazy. Here, the primary abstraction is something like > > ParallelStream or ParallelIterable. Let's call it ParallelFoo to avoid > > bikeshedding for the moment. Now, the code looks like: > > > > maxFooWeight = things.asParallelFoo() > > .filter(#Thing.isFoo) > > .map(#Thing.getWeight) > > .max(); > > > > Again, the return type of ParallelFoo.filter is different from > > Stream.filter or Collection.filter, so again the choice is reflected in > > the static type system. But you don't have to rewrite your code. > > > > The beauty here is twofold: > > > > - The base model (serial/eager) is easy to understand and natural to > > use as a way of expressing what the programmer wants to do, and > > attractive enough to stand on its own -- just a little slow with big > > collections. > > - Switching between execution models is mostly a matter of adding an > > explicit conversion or two in the call chain, as the models are similar > > enough that the rest of the code should still work (and even mean the > > same thing.) > > > > > > On 3/8/2011 8:43 AM, R?mi Forax wrote: > > > Le 08/03/2011 14:31, Jim Mayer a ?crit : > > >> // I can tolerate this one > > >> long product(List list) { > > >> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> > sum > > * x}); > > >> } > > > > > > I prefer this one: > > > > > > long product(List list) { > > > return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, x > -> > > sum * x}); > > > } > > > > > > lazy() means, don't do map directly, but wait and do map and reduce in > > > one iteration. > > > > > > R?mi > > > > > > > > > > > > From int19h at gmail.com Sat Mar 12 20:08:51 2011 From: int19h at gmail.com (Pavel Minaev) Date: Sat, 12 Mar 2011 20:08:51 -0800 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: I'm curious as to why you think that limiting lazy operations to iterators (or streams - the name is immaterial) is undesirable? In terms of code, it is exactly the same as the proposal which started the thread, with a need for one extra method call - iterator() rather than asStream() - on the collection, before you are in the lazy land. In terms of semantics, it avoids introduction of new abstractions where existing ones are sufficient to capture the intent (iterators are inherently lazy). On Sat, Mar 12, 2011 at 7:53 PM, Colin Decker wrote: > I don't feel like a comparison to InputStream etc. makes much sense > considering "Stream" is an arbitrary name that can easily be changed to > something more appropriate ("Streamable", say). I also think it's a weakness > of the IO streams that they don't have an Iterable equivalent (like > InputSupplier from Guava). Regardless, limiting lazy filter/map to Iterator > would be... undesirable. I do think Iterator should have such methods as > well, though. > > -- > Colin > > > > On Sat, Mar 12, 2011 at 8:30 PM, Pavel Minaev wrote: > >> I've been re-reading the "Design for collection upgrades" thread, and had >> some thoughts on the nature of the Stream abstraction (for lazy/serial >> scenario) as originally outlined in Brian's post that kicked off the >> thread, >> and users expectations of what comes with that name. >> >> Per the proposal, it sounds like Stream is more or less a marker interface >> to indicate lazy operations, and not otherwise any different from >> Iterable. >> However, this isn't what "stream" has historically meant in imperative PLs >> and their frameworks. For some examples of what I mean, let me point at >> java.io.InputStream, or at C++ std::basic_istream. In both cases, the >> fundamental property of the streams - the one that is guaranteed to be >> supported by _any_ stream - is that you can read elements. InputStream >> also >> offers mark()/reset(), but those are conditionally supported, and so are >> not >> part of the basic contract of the abstraction; they could (one could even >> argue that, from a pure OOD approach, they should) just as well be moved >> to >> a more concrete interface that could be queried by clients instead of >> using >> markSupported(). >> >> The important thing with that basic contract is that once a value is read >> from a stream, it stays read: a stream by itself is a read-once sequence. >> There may be ways to obtain another stream that would re-read the same >> exact >> elements, but that would still be a new stream object. For streams that >> wrap >> some data store (e.g. FileInputStream or ByteArrayInputStream), the stream >> object is essentially a cursor into the store - it has a current position, >> which every read advances towards the end of the store. Furthermore, the >> stream is not _the_ store - you can have several FileInputStreams over the >> same file, or several ByteArrayInputStreams sharing the same byte array. >> >> Now if we take the above and see how it applies to collections, it >> actually >> is a very familiar concept: something that is not a collection itself, but >> is a forward-only cursor for a collection, and each collection may have >> more >> than one such cursor - why, that is Iterator. Its next() and hasNext() >> methods match exactly the basic input stream contract; remove() does not, >> but it is conditionally-supported anyway. An analogy to highlight this >> point: Iterator is to Iterable/Collection what ByteArrayInputStream is to >> byte array. >> >> Iterators, being cursors, are also naturally expected to be lazy by API >> clients - if I provide a method that takes an iterator, applies a filter >> to >> it, and returns another iterator as a result, no-one would expect >> filtering >> to occur over the entire collection right there and then. It's clear that >> the result of such operation is a "filtered iterator", that would apply >> the >> filter as it is being iterated. >> >> So, then, why not put lazy map/filter/reduce/... on Iterator? Thus, >> Brian's >> original serial/lazy example would become: >> >> maxFooWeight = things.iterator() >> .filter(#Thing.isFoo) >> .map(#Thing.getWeight) >> .max(); >> >> or maybe with some less concise but more descriptive (and - purely >> subjectively - "Java-like") names: >> >> maxFooWeight = things.iterator() >> .withFilter(#Thing.isFoo) >> .withTransform(#Thing.getWeight) >> .getLargestValue(); >> >> This has a nice property of working with a more fundamental abstraction >> than >> collections - I can write an Iterator that wraps a non-rewindable I/O >> InputStream, but I cannot write such an Iterable (well, I can - if it >> throws >> after the first call to iterator() - but it will only be usable with APIs >> which specify that they only call iterator() on the provided Iterable once >> as part of their public contract; otherwise, I'm relying on an >> implementation detail). >> >> The only major annoyance I can see with this approach is that >> enhanced-for-loop only supports Iterables (and arrays) but not Iterators, >> and so you'd have to write a manual loop with next()/hasNext() to iterate >> over the result. But is there any reason why enhanced-for cannot be made >> to >> support Iterators directly? The only thing it does to the provided >> Iterable >> is to call iterator() on it, and it does it exactly once; it would just >> need >> to use the provided Iterator directly instead. It sounds like it would be >> trivial to add. >> >> >> The above didn't touch on what the design would look like for eager or >> lazy/parallel operations. For parallel, the original design can be >> trivially >> adapted by moving asParallel() to Iterator directly, and producing some >> sort >> of ParallelIterator, which is simply a marker interface to enable >> parallelization for all applied operations, but otherwise is the same as >> Iterator (probably just extending it). >> >> For eager operations, I would prefer in-place mutating methods returning >> the >> receiver (to permit chaining), with distinct but obviously mapped names. >> For >> example, if Iterator has withFilter(), then Collection would have >> filter(). >> I don't think there is much utility in having eager ops that do a copy, >> and >> even less so for chaining such. I think a simple addition of something >> like >> clone() to Collection (default implementation could do newInstance() >> assuming a no-arg constructor available, and then addAll(this) on that new >> instance) would cover vast majority of all cases where you want to get a >> copy: the usual pattern would then be to do something like: >> >> Collection getWeights() { >> return things.clone().filter(#Thing.isFoo). >> transform(#Thing.getWeight); >> } >> >> where both filter() and map() operate in-place on the cloned collection. >> This also skirts the whole question of the type of the resulting >> collection >> produced by a copying operation - it's clear and unambiguous what it'll be >> for clone(), and no other operation makes a copy. >> >> >> On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz >> wrote: >> >> > Since people are already discussing this based on an experimental >> > checkin, let me outline the big picture plan here. >> > >> > The general idea is to add functional-like operations to collections -- >> > filter, map, reduce, apply. >> > >> > I see three sensible modes, with explicit choices of which you get. >> > >> > 1. Serial / Eager. This is the straight >> > collections-with-functional-style mode, and some samples have already >> > been checked in as proof of concept. Operations on collections yield >> > new collections, and you can chain the calls. It values ease of use >> > over performance (no new concepts like laziness), but the performance >> > model is still highly predictable. You get things like >> > >> > Collection fooAbles = things.filter( #{ t -> t.isFoo() }); >> > >> > or, with method references: >> > >> > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty >> > >> > You can also chain calls together, though you pay a (predictable) >> > performance cost of intermediate collections, which for small >> > collections is unlikely to matter: >> > >> > maxFooWeight = things.filter(#Thing.isFoo) >> > .map(#Thing.getWeight) >> > .max(); >> > >> > The benefit here is concision and clarity. The cost is some >> > performance, but maybe not so much that people freak out. If people >> > care, they move to the next model, which is: >> > >> > 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be >> > chosen later, Remi used "lazy" in his example.) To transfer between >> > "eager world" and "lazy world", you use conversion methods (toStream / >> > toCollection). A typical call chain probably looks like: >> > collection.toStream / op / op / op / {toCollection,reduce,apply} >> > >> > so the above example becomes >> > >> > maxFooWeight = things.asStream() >> > .filter(#Thing.isFoo) >> > .map(#Thing.getWeight) >> > .max(); >> > >> > The return type of Collection.filter is different from the return type >> > of Stream.filter, so the choice and performance costs are reflected in >> > the static type system. This avoids the cost of the intermediate >> > collections, but is still serial. If you care about that, you move up >> > to the next model, which is: >> > >> > 3. Parallel / Lazy. Here, the primary abstraction is something like >> > ParallelStream or ParallelIterable. Let's call it ParallelFoo to avoid >> > bikeshedding for the moment. Now, the code looks like: >> > >> > maxFooWeight = things.asParallelFoo() >> > .filter(#Thing.isFoo) >> > .map(#Thing.getWeight) >> > .max(); >> > >> > Again, the return type of ParallelFoo.filter is different from >> > Stream.filter or Collection.filter, so again the choice is reflected in >> > the static type system. But you don't have to rewrite your code. >> > >> > The beauty here is twofold: >> > >> > - The base model (serial/eager) is easy to understand and natural to >> > use as a way of expressing what the programmer wants to do, and >> > attractive enough to stand on its own -- just a little slow with big >> > collections. >> > - Switching between execution models is mostly a matter of adding an >> > explicit conversion or two in the call chain, as the models are similar >> > enough that the rest of the code should still work (and even mean the >> > same thing.) >> > >> > >> > On 3/8/2011 8:43 AM, R?mi Forax wrote: >> > > Le 08/03/2011 14:31, Jim Mayer a ?crit : >> > >> // I can tolerate this one >> > >> long product(List list) { >> > >> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> >> sum >> > * x}); >> > >> } >> > > >> > > I prefer this one: >> > > >> > > long product(List list) { >> > > return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, x >> -> >> > sum * x}); >> > > } >> > > >> > > lazy() means, don't do map directly, but wait and do map and reduce in >> > > one iteration. >> > > >> > > R?mi >> > > >> > > >> > >> > >> >> > From cgdecker at gmail.com Sat Mar 12 20:37:21 2011 From: cgdecker at gmail.com (Colin Decker) Date: Sat, 12 Mar 2011 23:37:21 -0500 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: Because there's no need to and because Iterables (being reusable) are far more flexible than Iterators. The Iterable interface is just as lazy as Iterator. The Stream interface should be Iterable. -- Colin On Sat, Mar 12, 2011 at 11:08 PM, Pavel Minaev wrote: > I'm curious as to why you think that limiting lazy operations to iterators > (or streams - the name is immaterial) is undesirable? In terms of code, it > is exactly the same as the proposal which started the thread, with a need > for one extra method call - iterator() rather than asStream() - on the > collection, before you are in the lazy land. In terms of semantics, it > avoids introduction of new abstractions where existing ones are sufficient > to capture the intent (iterators are inherently lazy). > > On Sat, Mar 12, 2011 at 7:53 PM, Colin Decker wrote: > >> I don't feel like a comparison to InputStream etc. makes much sense >> considering "Stream" is an arbitrary name that can easily be changed to >> something more appropriate ("Streamable", say). I also think it's a weakness >> of the IO streams that they don't have an Iterable equivalent (like >> InputSupplier from Guava). Regardless, limiting lazy filter/map to Iterator >> would be... undesirable. I do think Iterator should have such methods as >> well, though. >> >> -- >> Colin >> >> >> >> On Sat, Mar 12, 2011 at 8:30 PM, Pavel Minaev wrote: >> >>> I've been re-reading the "Design for collection upgrades" thread, and had >>> some thoughts on the nature of the Stream abstraction (for lazy/serial >>> scenario) as originally outlined in Brian's post that kicked off the >>> thread, >>> and users expectations of what comes with that name. >>> >>> Per the proposal, it sounds like Stream is more or less a marker >>> interface >>> to indicate lazy operations, and not otherwise any different from >>> Iterable. >>> However, this isn't what "stream" has historically meant in imperative >>> PLs >>> and their frameworks. For some examples of what I mean, let me point at >>> java.io.InputStream, or at C++ std::basic_istream. In both cases, the >>> fundamental property of the streams - the one that is guaranteed to be >>> supported by _any_ stream - is that you can read elements. InputStream >>> also >>> offers mark()/reset(), but those are conditionally supported, and so are >>> not >>> part of the basic contract of the abstraction; they could (one could even >>> argue that, from a pure OOD approach, they should) just as well be moved >>> to >>> a more concrete interface that could be queried by clients instead of >>> using >>> markSupported(). >>> >>> The important thing with that basic contract is that once a value is read >>> from a stream, it stays read: a stream by itself is a read-once sequence. >>> There may be ways to obtain another stream that would re-read the same >>> exact >>> elements, but that would still be a new stream object. For streams that >>> wrap >>> some data store (e.g. FileInputStream or ByteArrayInputStream), the >>> stream >>> object is essentially a cursor into the store - it has a current >>> position, >>> which every read advances towards the end of the store. Furthermore, the >>> stream is not _the_ store - you can have several FileInputStreams over >>> the >>> same file, or several ByteArrayInputStreams sharing the same byte array. >>> >>> Now if we take the above and see how it applies to collections, it >>> actually >>> is a very familiar concept: something that is not a collection itself, >>> but >>> is a forward-only cursor for a collection, and each collection may have >>> more >>> than one such cursor - why, that is Iterator. Its next() and hasNext() >>> methods match exactly the basic input stream contract; remove() does not, >>> but it is conditionally-supported anyway. An analogy to highlight this >>> point: Iterator is to Iterable/Collection what ByteArrayInputStream is to >>> byte array. >>> >>> Iterators, being cursors, are also naturally expected to be lazy by API >>> clients - if I provide a method that takes an iterator, applies a filter >>> to >>> it, and returns another iterator as a result, no-one would expect >>> filtering >>> to occur over the entire collection right there and then. It's clear that >>> the result of such operation is a "filtered iterator", that would apply >>> the >>> filter as it is being iterated. >>> >>> So, then, why not put lazy map/filter/reduce/... on Iterator? Thus, >>> Brian's >>> original serial/lazy example would become: >>> >>> maxFooWeight = things.iterator() >>> .filter(#Thing.isFoo) >>> .map(#Thing.getWeight) >>> .max(); >>> >>> or maybe with some less concise but more descriptive (and - purely >>> subjectively - "Java-like") names: >>> >>> maxFooWeight = things.iterator() >>> .withFilter(#Thing.isFoo) >>> .withTransform(#Thing.getWeight) >>> .getLargestValue(); >>> >>> This has a nice property of working with a more fundamental abstraction >>> than >>> collections - I can write an Iterator that wraps a non-rewindable I/O >>> InputStream, but I cannot write such an Iterable (well, I can - if it >>> throws >>> after the first call to iterator() - but it will only be usable with APIs >>> which specify that they only call iterator() on the provided Iterable >>> once >>> as part of their public contract; otherwise, I'm relying on an >>> implementation detail). >>> >>> The only major annoyance I can see with this approach is that >>> enhanced-for-loop only supports Iterables (and arrays) but not Iterators, >>> and so you'd have to write a manual loop with next()/hasNext() to iterate >>> over the result. But is there any reason why enhanced-for cannot be made >>> to >>> support Iterators directly? The only thing it does to the provided >>> Iterable >>> is to call iterator() on it, and it does it exactly once; it would just >>> need >>> to use the provided Iterator directly instead. It sounds like it would be >>> trivial to add. >>> >>> >>> The above didn't touch on what the design would look like for eager or >>> lazy/parallel operations. For parallel, the original design can be >>> trivially >>> adapted by moving asParallel() to Iterator directly, and producing some >>> sort >>> of ParallelIterator, which is simply a marker interface to enable >>> parallelization for all applied operations, but otherwise is the same as >>> Iterator (probably just extending it). >>> >>> For eager operations, I would prefer in-place mutating methods returning >>> the >>> receiver (to permit chaining), with distinct but obviously mapped names. >>> For >>> example, if Iterator has withFilter(), then Collection would have >>> filter(). >>> I don't think there is much utility in having eager ops that do a copy, >>> and >>> even less so for chaining such. I think a simple addition of something >>> like >>> clone() to Collection (default implementation could do newInstance() >>> assuming a no-arg constructor available, and then addAll(this) on that >>> new >>> instance) would cover vast majority of all cases where you want to get a >>> copy: the usual pattern would then be to do something like: >>> >>> Collection getWeights() { >>> return things.clone().filter(#Thing.isFoo). >>> transform(#Thing.getWeight); >>> } >>> >>> where both filter() and map() operate in-place on the cloned collection. >>> This also skirts the whole question of the type of the resulting >>> collection >>> produced by a copying operation - it's clear and unambiguous what it'll >>> be >>> for clone(), and no other operation makes a copy. >>> >>> >>> On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz >>> wrote: >>> >>> > Since people are already discussing this based on an experimental >>> > checkin, let me outline the big picture plan here. >>> > >>> > The general idea is to add functional-like operations to collections -- >>> > filter, map, reduce, apply. >>> > >>> > I see three sensible modes, with explicit choices of which you get. >>> > >>> > 1. Serial / Eager. This is the straight >>> > collections-with-functional-style mode, and some samples have already >>> > been checked in as proof of concept. Operations on collections yield >>> > new collections, and you can chain the calls. It values ease of use >>> > over performance (no new concepts like laziness), but the performance >>> > model is still highly predictable. You get things like >>> > >>> > Collection fooAbles = things.filter( #{ t -> t.isFoo() }); >>> > >>> > or, with method references: >>> > >>> > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty >>> > >>> > You can also chain calls together, though you pay a (predictable) >>> > performance cost of intermediate collections, which for small >>> > collections is unlikely to matter: >>> > >>> > maxFooWeight = things.filter(#Thing.isFoo) >>> > .map(#Thing.getWeight) >>> > .max(); >>> > >>> > The benefit here is concision and clarity. The cost is some >>> > performance, but maybe not so much that people freak out. If people >>> > care, they move to the next model, which is: >>> > >>> > 2. Serial / Lazy. Here, the primary abstraction is Stream (name to be >>> > chosen later, Remi used "lazy" in his example.) To transfer between >>> > "eager world" and "lazy world", you use conversion methods (toStream / >>> > toCollection). A typical call chain probably looks like: >>> > collection.toStream / op / op / op / {toCollection,reduce,apply} >>> > >>> > so the above example becomes >>> > >>> > maxFooWeight = things.asStream() >>> > .filter(#Thing.isFoo) >>> > .map(#Thing.getWeight) >>> > .max(); >>> > >>> > The return type of Collection.filter is different from the return type >>> > of Stream.filter, so the choice and performance costs are reflected in >>> > the static type system. This avoids the cost of the intermediate >>> > collections, but is still serial. If you care about that, you move up >>> > to the next model, which is: >>> > >>> > 3. Parallel / Lazy. Here, the primary abstraction is something like >>> > ParallelStream or ParallelIterable. Let's call it ParallelFoo to avoid >>> > bikeshedding for the moment. Now, the code looks like: >>> > >>> > maxFooWeight = things.asParallelFoo() >>> > .filter(#Thing.isFoo) >>> > .map(#Thing.getWeight) >>> > .max(); >>> > >>> > Again, the return type of ParallelFoo.filter is different from >>> > Stream.filter or Collection.filter, so again the choice is reflected in >>> > the static type system. But you don't have to rewrite your code. >>> > >>> > The beauty here is twofold: >>> > >>> > - The base model (serial/eager) is easy to understand and natural to >>> > use as a way of expressing what the programmer wants to do, and >>> > attractive enough to stand on its own -- just a little slow with big >>> > collections. >>> > - Switching between execution models is mostly a matter of adding an >>> > explicit conversion or two in the call chain, as the models are similar >>> > enough that the rest of the code should still work (and even mean the >>> > same thing.) >>> > >>> > >>> > On 3/8/2011 8:43 AM, R?mi Forax wrote: >>> > > Le 08/03/2011 14:31, Jim Mayer a ?crit : >>> > >> // I can tolerate this one >>> > >> long product(List list) { >>> > >> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> >>> sum >>> > * x}); >>> > >> } >>> > > >>> > > I prefer this one: >>> > > >>> > > long product(List list) { >>> > > return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, >>> x -> >>> > sum * x}); >>> > > } >>> > > >>> > > lazy() means, don't do map directly, but wait and do map and reduce >>> in >>> > > one iteration. >>> > > >>> > > R?mi >>> > > >>> > > >>> > >>> > >>> >>> >> > From int19h at gmail.com Sat Mar 12 21:31:37 2011 From: int19h at gmail.com (Pavel Minaev) Date: Sat, 12 Mar 2011 21:31:37 -0800 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: I argued for that as well, originally, but then operations on all collections would be lazy (as they are all Iterables). On the other hand, if specific collections override operations and redefine them as eager, we get an undesired inconsistency in behavior - some Iterables are lazy, while others are not. The best you can then do is provide some kind of toIterable() method on any Iterable, which would wrap it into a simple lazy Iterable with default implementations for map/filter/..., hiding any overriden behavior - and then you also have to explain to the users the difference between writing ((Iterable)list).map() and list.toIterable().map(). In contrast, iterator functions (as in, a function taking an iterator and returning a new iterator) are always perceived as lazy, whether the original iterator was obtained from a collection or not. I understand that this is not a strict argument, and it's all about what the API client "expects" to see, which is very subjective. But we've already had a lengthy argument on how to best name lazy operations such that they're not confused with eager operations provided by the collection itself; and that is mainly because the existing Java collection API is eager and mutable; and I see the reasons behind this argument. E.g. list.add() mutates the list in-place, right there and then; it does not defer the update until the list is iterated, nor does it create and return a new list - and so it's hard to argue against the claim that list.filter() should do things in an entirely different way. Hence the desire for some kind of list.magicalSomething().filter() that would clearly mark the transition to laziness. On Sat, Mar 12, 2011 at 8:37 PM, Colin Decker wrote: > Because there's no need to and because Iterables (being reusable) are far > more flexible than Iterators. The Iterable interface is just as lazy as > Iterator. The Stream interface should be Iterable. > > -- > Colin > > > > On Sat, Mar 12, 2011 at 11:08 PM, Pavel Minaev wrote: > >> I'm curious as to why you think that limiting lazy operations to iterators >> (or streams - the name is immaterial) is undesirable? In terms of code, it >> is exactly the same as the proposal which started the thread, with a need >> for one extra method call - iterator() rather than asStream() - on the >> collection, before you are in the lazy land. In terms of semantics, it >> avoids introduction of new abstractions where existing ones are sufficient >> to capture the intent (iterators are inherently lazy). >> >> On Sat, Mar 12, 2011 at 7:53 PM, Colin Decker wrote: >> >>> I don't feel like a comparison to InputStream etc. makes much sense >>> considering "Stream" is an arbitrary name that can easily be changed to >>> something more appropriate ("Streamable", say). I also think it's a weakness >>> of the IO streams that they don't have an Iterable equivalent (like >>> InputSupplier from Guava). Regardless, limiting lazy filter/map to Iterator >>> would be... undesirable. I do think Iterator should have such methods as >>> well, though. >>> >>> -- >>> Colin >>> >>> >>> >>> On Sat, Mar 12, 2011 at 8:30 PM, Pavel Minaev wrote: >>> >>>> I've been re-reading the "Design for collection upgrades" thread, and >>>> had >>>> some thoughts on the nature of the Stream abstraction (for lazy/serial >>>> scenario) as originally outlined in Brian's post that kicked off the >>>> thread, >>>> and users expectations of what comes with that name. >>>> >>>> Per the proposal, it sounds like Stream is more or less a marker >>>> interface >>>> to indicate lazy operations, and not otherwise any different from >>>> Iterable. >>>> However, this isn't what "stream" has historically meant in imperative >>>> PLs >>>> and their frameworks. For some examples of what I mean, let me point at >>>> java.io.InputStream, or at C++ std::basic_istream. In both cases, the >>>> fundamental property of the streams - the one that is guaranteed to be >>>> supported by _any_ stream - is that you can read elements. InputStream >>>> also >>>> offers mark()/reset(), but those are conditionally supported, and so are >>>> not >>>> part of the basic contract of the abstraction; they could (one could >>>> even >>>> argue that, from a pure OOD approach, they should) just as well be moved >>>> to >>>> a more concrete interface that could be queried by clients instead of >>>> using >>>> markSupported(). >>>> >>>> The important thing with that basic contract is that once a value is >>>> read >>>> from a stream, it stays read: a stream by itself is a read-once >>>> sequence. >>>> There may be ways to obtain another stream that would re-read the same >>>> exact >>>> elements, but that would still be a new stream object. For streams that >>>> wrap >>>> some data store (e.g. FileInputStream or ByteArrayInputStream), the >>>> stream >>>> object is essentially a cursor into the store - it has a current >>>> position, >>>> which every read advances towards the end of the store. Furthermore, the >>>> stream is not _the_ store - you can have several FileInputStreams over >>>> the >>>> same file, or several ByteArrayInputStreams sharing the same byte array. >>>> >>>> Now if we take the above and see how it applies to collections, it >>>> actually >>>> is a very familiar concept: something that is not a collection itself, >>>> but >>>> is a forward-only cursor for a collection, and each collection may have >>>> more >>>> than one such cursor - why, that is Iterator. Its next() and hasNext() >>>> methods match exactly the basic input stream contract; remove() does >>>> not, >>>> but it is conditionally-supported anyway. An analogy to highlight this >>>> point: Iterator is to Iterable/Collection what ByteArrayInputStream is >>>> to >>>> byte array. >>>> >>>> Iterators, being cursors, are also naturally expected to be lazy by API >>>> clients - if I provide a method that takes an iterator, applies a filter >>>> to >>>> it, and returns another iterator as a result, no-one would expect >>>> filtering >>>> to occur over the entire collection right there and then. It's clear >>>> that >>>> the result of such operation is a "filtered iterator", that would apply >>>> the >>>> filter as it is being iterated. >>>> >>>> So, then, why not put lazy map/filter/reduce/... on Iterator? Thus, >>>> Brian's >>>> original serial/lazy example would become: >>>> >>>> maxFooWeight = things.iterator() >>>> .filter(#Thing.isFoo) >>>> .map(#Thing.getWeight) >>>> .max(); >>>> >>>> or maybe with some less concise but more descriptive (and - purely >>>> subjectively - "Java-like") names: >>>> >>>> maxFooWeight = things.iterator() >>>> .withFilter(#Thing.isFoo) >>>> .withTransform(#Thing.getWeight) >>>> .getLargestValue(); >>>> >>>> This has a nice property of working with a more fundamental abstraction >>>> than >>>> collections - I can write an Iterator that wraps a non-rewindable I/O >>>> InputStream, but I cannot write such an Iterable (well, I can - if it >>>> throws >>>> after the first call to iterator() - but it will only be usable with >>>> APIs >>>> which specify that they only call iterator() on the provided Iterable >>>> once >>>> as part of their public contract; otherwise, I'm relying on an >>>> implementation detail). >>>> >>>> The only major annoyance I can see with this approach is that >>>> enhanced-for-loop only supports Iterables (and arrays) but not >>>> Iterators, >>>> and so you'd have to write a manual loop with next()/hasNext() to >>>> iterate >>>> over the result. But is there any reason why enhanced-for cannot be made >>>> to >>>> support Iterators directly? The only thing it does to the provided >>>> Iterable >>>> is to call iterator() on it, and it does it exactly once; it would just >>>> need >>>> to use the provided Iterator directly instead. It sounds like it would >>>> be >>>> trivial to add. >>>> >>>> >>>> The above didn't touch on what the design would look like for eager or >>>> lazy/parallel operations. For parallel, the original design can be >>>> trivially >>>> adapted by moving asParallel() to Iterator directly, and producing some >>>> sort >>>> of ParallelIterator, which is simply a marker interface to enable >>>> parallelization for all applied operations, but otherwise is the same as >>>> Iterator (probably just extending it). >>>> >>>> For eager operations, I would prefer in-place mutating methods returning >>>> the >>>> receiver (to permit chaining), with distinct but obviously mapped names. >>>> For >>>> example, if Iterator has withFilter(), then Collection would have >>>> filter(). >>>> I don't think there is much utility in having eager ops that do a copy, >>>> and >>>> even less so for chaining such. I think a simple addition of something >>>> like >>>> clone() to Collection (default implementation could do newInstance() >>>> assuming a no-arg constructor available, and then addAll(this) on that >>>> new >>>> instance) would cover vast majority of all cases where you want to get a >>>> copy: the usual pattern would then be to do something like: >>>> >>>> Collection getWeights() { >>>> return things.clone().filter(#Thing.isFoo). >>>> transform(#Thing.getWeight); >>>> } >>>> >>>> where both filter() and map() operate in-place on the cloned collection. >>>> This also skirts the whole question of the type of the resulting >>>> collection >>>> produced by a copying operation - it's clear and unambiguous what it'll >>>> be >>>> for clone(), and no other operation makes a copy. >>>> >>>> >>>> On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz >>>> wrote: >>>> >>>> > Since people are already discussing this based on an experimental >>>> > checkin, let me outline the big picture plan here. >>>> > >>>> > The general idea is to add functional-like operations to collections >>>> -- >>>> > filter, map, reduce, apply. >>>> > >>>> > I see three sensible modes, with explicit choices of which you get. >>>> > >>>> > 1. Serial / Eager. This is the straight >>>> > collections-with-functional-style mode, and some samples have already >>>> > been checked in as proof of concept. Operations on collections yield >>>> > new collections, and you can chain the calls. It values ease of use >>>> > over performance (no new concepts like laziness), but the performance >>>> > model is still highly predictable. You get things like >>>> > >>>> > Collection fooAbles = things.filter( #{ t -> t.isFoo() }); >>>> > >>>> > or, with method references: >>>> > >>>> > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, pretty >>>> > >>>> > You can also chain calls together, though you pay a (predictable) >>>> > performance cost of intermediate collections, which for small >>>> > collections is unlikely to matter: >>>> > >>>> > maxFooWeight = things.filter(#Thing.isFoo) >>>> > .map(#Thing.getWeight) >>>> > .max(); >>>> > >>>> > The benefit here is concision and clarity. The cost is some >>>> > performance, but maybe not so much that people freak out. If people >>>> > care, they move to the next model, which is: >>>> > >>>> > 2. Serial / Lazy. Here, the primary abstraction is Stream (name to >>>> be >>>> > chosen later, Remi used "lazy" in his example.) To transfer between >>>> > "eager world" and "lazy world", you use conversion methods (toStream / >>>> > toCollection). A typical call chain probably looks like: >>>> > collection.toStream / op / op / op / {toCollection,reduce,apply} >>>> > >>>> > so the above example becomes >>>> > >>>> > maxFooWeight = things.asStream() >>>> > .filter(#Thing.isFoo) >>>> > .map(#Thing.getWeight) >>>> > .max(); >>>> > >>>> > The return type of Collection.filter is different from the return type >>>> > of Stream.filter, so the choice and performance costs are reflected in >>>> > the static type system. This avoids the cost of the intermediate >>>> > collections, but is still serial. If you care about that, you move up >>>> > to the next model, which is: >>>> > >>>> > 3. Parallel / Lazy. Here, the primary abstraction is something like >>>> > ParallelStream or ParallelIterable. Let's call it ParallelFoo to >>>> avoid >>>> > bikeshedding for the moment. Now, the code looks like: >>>> > >>>> > maxFooWeight = things.asParallelFoo() >>>> > .filter(#Thing.isFoo) >>>> > .map(#Thing.getWeight) >>>> > .max(); >>>> > >>>> > Again, the return type of ParallelFoo.filter is different from >>>> > Stream.filter or Collection.filter, so again the choice is reflected >>>> in >>>> > the static type system. But you don't have to rewrite your code. >>>> > >>>> > The beauty here is twofold: >>>> > >>>> > - The base model (serial/eager) is easy to understand and natural to >>>> > use as a way of expressing what the programmer wants to do, and >>>> > attractive enough to stand on its own -- just a little slow with big >>>> > collections. >>>> > - Switching between execution models is mostly a matter of adding an >>>> > explicit conversion or two in the call chain, as the models are >>>> similar >>>> > enough that the rest of the code should still work (and even mean the >>>> > same thing.) >>>> > >>>> > >>>> > On 3/8/2011 8:43 AM, R?mi Forax wrote: >>>> > > Le 08/03/2011 14:31, Jim Mayer a ?crit : >>>> > >> // I can tolerate this one >>>> > >> long product(List list) { >>>> > >> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> >>>> sum >>>> > * x}); >>>> > >> } >>>> > > >>>> > > I prefer this one: >>>> > > >>>> > > long product(List list) { >>>> > > return list.lazy().map(#{x -> (long) x}).reduce(0L, #{sum, >>>> x -> >>>> > sum * x}); >>>> > > } >>>> > > >>>> > > lazy() means, don't do map directly, but wait and do map and reduce >>>> in >>>> > > one iteration. >>>> > > >>>> > > R?mi >>>> > > >>>> > > >>>> > >>>> > >>>> >>>> >>> >> > From ss at comp.lancs.ac.uk Sun Mar 13 04:12:23 2011 From: ss at comp.lancs.ac.uk (Steven Simpson) Date: Sun, 13 Mar 2011 11:12:23 +0000 Subject: Design for collections upgrades In-Reply-To: <4D78D8CB.4020801@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> Message-ID: <4D7CA697.7080300@comp.lancs.ac.uk> On 10/03/11 13:57, R?mi Forax wrote: > Yes, we need to provide methods that filter/map directly > the content of a collections. > But I don't think it's a good idea to name them filter or map. > > Why not filterAll and mapAll ? I'm starting to lose track of this thread, but I recall the following points: * Lazy operations are desirable, as are eager ones, and in-place ones. * There could be a type or family thereof for lazy collections, e.g. Stream or Iterable. * Collections currently don't have methods for generating new collections, so adding them is a considerable shift. They do have in-place methods, and new methods like 'filter' share the same tense, suggesting that they should be in-place methods too. In case it hasn't yet been mentioned, I'd like to add that collections also support /views/ in several places, e.g. subList, entrySet, etc. Do we need a lazy type when we can have views? I haven't pinned it down in my mind yet, but I suspect that views are slightly different to streams, in that they also allow us to modify the original collection. Or, to put it another way, they differ from mutating methods, in that we can choose not to perform any mutation. When we want to delete a portion of a list, we write: list.subList(a, b).clear() ...because the sublist view allows us to modify the original list. But if we want to extract a sublist, and leave the original untouched, we write: new ArrayList(list.subList(a, b)) List.subList could be regarded as lazy, until we apply a mutating method to it like clear(). And if we never do that, it stays lazy even while we do an eager copy. Can we do the same with filter (using a noun like "selection" to be consistent with subList)? list.selection(pred).clear(); // mutating original; removeAll(pred)? new ArrayList(list.selection(pred)); // preserving original Views, having ordinary collection types, remain Iterable too: for (Element elem : list.selection(pred)) { ... } I suppose my point is that there is already a precedent for (mutable) laziness in the collection framework, in the form of views. Cheers, Steven -- From forax at univ-mlv.fr Sun Mar 13 04:36:02 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Sun, 13 Mar 2011 12:36:02 +0100 Subject: Design for collections upgrades In-Reply-To: <4D7CA697.7080300@comp.lancs.ac.uk> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7CA697.7080300@comp.lancs.ac.uk> Message-ID: <4D7CAC22.9020901@univ-mlv.fr> Good point. Some collections has views but this view are also collection of the same type. This is not the case of filter/map, set.filter() can't return a Set. So the result of filter/map is not a view as we know it. filter/map can returns an Iterable or a Collection (or a Stream that inherits from Iterable or Collection, if we want a clean separation between eager/lazy world). So for me the question is: should filter/map return something that is more like an Iterable or more like a Collection. There is one advantage to use Collection instead of Iterable, which is the interoperability with bulk operations (addAll, retainAll, containsAll, etc.). R?mi On 03/13/2011 12:12 PM, Steven Simpson wrote: > On 10/03/11 13:57, R?mi Forax wrote: >> Yes, we need to provide methods that filter/map directly >> the content of a collections. >> But I don't think it's a good idea to name them filter or map. >> >> Why not filterAll and mapAll ? > I'm starting to lose track of this thread, but I recall the following > points: > > * Lazy operations are desirable, as are eager ones, and in-place ones. > * There could be a type or family thereof for lazy collections, e.g. > Stream or Iterable. > * Collections currently don't have methods for generating new > collections, so adding them is a considerable shift. They do have > in-place methods, and new methods like 'filter' share the same > tense, suggesting that they should be in-place methods too. > > In case it hasn't yet been mentioned, I'd like to add that collections > also support /views/ in several places, e.g. subList, entrySet, etc. Do > we need a lazy type when we can have views? I haven't pinned it down in > my mind yet, but I suspect that views are slightly different to streams, > in that they also allow us to modify the original collection. Or, to > put it another way, they differ from mutating methods, in that we can > choose not to perform any mutation. > > When we want to delete a portion of a list, we write: > > list.subList(a, b).clear() > > ...because the sublist view allows us to modify the original list. But > if we want to extract a sublist, and leave the original untouched, we write: > > new ArrayList(list.subList(a, b)) > > List.subList could be regarded as lazy, until we apply a mutating method > to it like clear(). And if we never do that, it stays lazy even while > we do an eager copy. > > Can we do the same with filter (using a noun like "selection" to be > consistent with subList)? > > list.selection(pred).clear(); // mutating original; removeAll(pred)? > new ArrayList(list.selection(pred)); // preserving original > > Views, having ordinary collection types, remain Iterable too: > > for (Element elem : list.selection(pred)) { ... } > > I suppose my point is that there is already a precedent for (mutable) > laziness in the collection framework, in the form of views. > > Cheers, > > Steven > From cgdecker at gmail.com Sun Mar 13 08:37:35 2011 From: cgdecker at gmail.com (Colin Decker) Date: Sun, 13 Mar 2011 11:37:35 -0400 Subject: Design for collections upgrades In-Reply-To: <4D7CAC22.9020901@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7CA697.7080300@comp.lancs.ac.uk> <4D7CAC22.9020901@univ-mlv.fr> Message-ID: Set.filter() can return a Set view and List.map() can return a List view. Of course, Set.map() can't very well return a Set view. -- Colin On Sun, Mar 13, 2011 at 7:36 AM, R?mi Forax wrote: > Good point. > Some collections has views but this view are also collection of the same > type. > > This is not the case of filter/map, set.filter() can't return a Set. > So the result of filter/map is not a view as we know it. > > filter/map can returns an Iterable or a Collection > (or a Stream that inherits from Iterable or Collection, > if we want a clean separation between eager/lazy world). > > So for me the question is: should filter/map return > something that is more like an Iterable or more like > a Collection. > > There is one advantage to use Collection instead of Iterable, > which is the interoperability with bulk operations (addAll, retainAll, > containsAll, etc.). > > R?mi > > On 03/13/2011 12:12 PM, Steven Simpson wrote: > > On 10/03/11 13:57, R?mi Forax wrote: > >> Yes, we need to provide methods that filter/map directly > >> the content of a collections. > >> But I don't think it's a good idea to name them filter or map. > >> > >> Why not filterAll and mapAll ? > > I'm starting to lose track of this thread, but I recall the following > > points: > > > > * Lazy operations are desirable, as are eager ones, and in-place > ones. > > * There could be a type or family thereof for lazy collections, e.g. > > Stream or Iterable. > > * Collections currently don't have methods for generating new > > collections, so adding them is a considerable shift. They do have > > in-place methods, and new methods like 'filter' share the same > > tense, suggesting that they should be in-place methods too. > > > > In case it hasn't yet been mentioned, I'd like to add that collections > > also support /views/ in several places, e.g. subList, entrySet, etc. Do > > we need a lazy type when we can have views? I haven't pinned it down in > > my mind yet, but I suspect that views are slightly different to streams, > > in that they also allow us to modify the original collection. Or, to > > put it another way, they differ from mutating methods, in that we can > > choose not to perform any mutation. > > > > When we want to delete a portion of a list, we write: > > > > list.subList(a, b).clear() > > > > ...because the sublist view allows us to modify the original list. But > > if we want to extract a sublist, and leave the original untouched, we > write: > > > > new ArrayList(list.subList(a, b)) > > > > List.subList could be regarded as lazy, until we apply a mutating method > > to it like clear(). And if we never do that, it stays lazy even while > > we do an eager copy. > > > > Can we do the same with filter (using a noun like "selection" to be > > consistent with subList)? > > > > list.selection(pred).clear(); // mutating original; removeAll(pred)? > > new ArrayList(list.selection(pred)); // preserving original > > > > Views, having ordinary collection types, remain Iterable too: > > > > for (Element elem : list.selection(pred)) { ... } > > > > I suppose my point is that there is already a precedent for (mutable) > > laziness in the collection framework, in the form of views. > > > > Cheers, > > > > Steven > > > > > From cgdecker at gmail.com Sun Mar 13 08:54:20 2011 From: cgdecker at gmail.com (Colin Decker) Date: Sun, 13 Mar 2011 11:54:20 -0400 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: If it isn't acceptable to have lazy methods on Collections then yes, something like "asStream()" or whatever is needed. That would cleanly delineate the lazy operations from the eager/mutating operations and I don't think it would be confusing. All I'm saying is that there's no need to make the primary type that lazy operations can be used with implement the strictly less useful Iterator when it could easily implement Iterable. -- Colin On Sun, Mar 13, 2011 at 12:31 AM, Pavel Minaev wrote: > I argued for that as well, originally, but then operations on all > collections would be lazy (as they are all Iterables). On the other hand, if > specific collections override operations and redefine them as eager, we get > an undesired inconsistency in behavior - some Iterables are lazy, while > others are not. The best you can then do is provide some kind of > toIterable() method on any Iterable, which would wrap it into a simple lazy > Iterable with default implementations for map/filter/..., hiding any > overriden behavior - and then you also have to explain to the users the > difference between writing ((Iterable)list).map() and > list.toIterable().map(). In contrast, iterator functions (as in, a function > taking an iterator and returning a new iterator) are always perceived as > lazy, whether the original iterator was obtained from a collection or not. > > I understand that this is not a strict argument, and it's all about what > the API client "expects" to see, which is very subjective. But we've already > had a lengthy argument on how to best name lazy operations such that they're > not confused with eager operations provided by the collection itself; and > that is mainly because the existing Java collection API is eager and > mutable; and I see the reasons behind this argument. E.g. list.add() mutates > the list in-place, right there and then; it does not defer the update until > the list is iterated, nor does it create and return a new list - and so it's > hard to argue against the claim that list.filter() should do things in an > entirely different way. Hence the desire for some kind of > list.magicalSomething().filter() that would clearly mark the transition to > laziness. > > > On Sat, Mar 12, 2011 at 8:37 PM, Colin Decker wrote: > >> Because there's no need to and because Iterables (being reusable) are far >> more flexible than Iterators. The Iterable interface is just as lazy as >> Iterator. The Stream interface should be Iterable. >> >> -- >> Colin >> >> >> >> On Sat, Mar 12, 2011 at 11:08 PM, Pavel Minaev wrote: >> >>> I'm curious as to why you think that limiting lazy operations to >>> iterators (or streams - the name is immaterial) is undesirable? In terms of >>> code, it is exactly the same as the proposal which started the thread, with >>> a need for one extra method call - iterator() rather than asStream() - on >>> the collection, before you are in the lazy land. In terms of semantics, it >>> avoids introduction of new abstractions where existing ones are sufficient >>> to capture the intent (iterators are inherently lazy). >>> >>> On Sat, Mar 12, 2011 at 7:53 PM, Colin Decker wrote: >>> >>>> I don't feel like a comparison to InputStream etc. makes much sense >>>> considering "Stream" is an arbitrary name that can easily be changed to >>>> something more appropriate ("Streamable", say). I also think it's a weakness >>>> of the IO streams that they don't have an Iterable equivalent (like >>>> InputSupplier from Guava). Regardless, limiting lazy filter/map to Iterator >>>> would be... undesirable. I do think Iterator should have such methods as >>>> well, though. >>>> >>>> -- >>>> Colin >>>> >>>> >>>> >>>> On Sat, Mar 12, 2011 at 8:30 PM, Pavel Minaev wrote: >>>> >>>>> I've been re-reading the "Design for collection upgrades" thread, and >>>>> had >>>>> some thoughts on the nature of the Stream abstraction (for lazy/serial >>>>> scenario) as originally outlined in Brian's post that kicked off the >>>>> thread, >>>>> and users expectations of what comes with that name. >>>>> >>>>> Per the proposal, it sounds like Stream is more or less a marker >>>>> interface >>>>> to indicate lazy operations, and not otherwise any different from >>>>> Iterable. >>>>> However, this isn't what "stream" has historically meant in imperative >>>>> PLs >>>>> and their frameworks. For some examples of what I mean, let me point at >>>>> java.io.InputStream, or at C++ std::basic_istream. In both cases, the >>>>> fundamental property of the streams - the one that is guaranteed to be >>>>> supported by _any_ stream - is that you can read elements. InputStream >>>>> also >>>>> offers mark()/reset(), but those are conditionally supported, and so >>>>> are not >>>>> part of the basic contract of the abstraction; they could (one could >>>>> even >>>>> argue that, from a pure OOD approach, they should) just as well be >>>>> moved to >>>>> a more concrete interface that could be queried by clients instead of >>>>> using >>>>> markSupported(). >>>>> >>>>> The important thing with that basic contract is that once a value is >>>>> read >>>>> from a stream, it stays read: a stream by itself is a read-once >>>>> sequence. >>>>> There may be ways to obtain another stream that would re-read the same >>>>> exact >>>>> elements, but that would still be a new stream object. For streams that >>>>> wrap >>>>> some data store (e.g. FileInputStream or ByteArrayInputStream), the >>>>> stream >>>>> object is essentially a cursor into the store - it has a current >>>>> position, >>>>> which every read advances towards the end of the store. Furthermore, >>>>> the >>>>> stream is not _the_ store - you can have several FileInputStreams over >>>>> the >>>>> same file, or several ByteArrayInputStreams sharing the same byte >>>>> array. >>>>> >>>>> Now if we take the above and see how it applies to collections, it >>>>> actually >>>>> is a very familiar concept: something that is not a collection itself, >>>>> but >>>>> is a forward-only cursor for a collection, and each collection may have >>>>> more >>>>> than one such cursor - why, that is Iterator. Its next() and hasNext() >>>>> methods match exactly the basic input stream contract; remove() does >>>>> not, >>>>> but it is conditionally-supported anyway. An analogy to highlight this >>>>> point: Iterator is to Iterable/Collection what ByteArrayInputStream is >>>>> to >>>>> byte array. >>>>> >>>>> Iterators, being cursors, are also naturally expected to be lazy by API >>>>> clients - if I provide a method that takes an iterator, applies a >>>>> filter to >>>>> it, and returns another iterator as a result, no-one would expect >>>>> filtering >>>>> to occur over the entire collection right there and then. It's clear >>>>> that >>>>> the result of such operation is a "filtered iterator", that would apply >>>>> the >>>>> filter as it is being iterated. >>>>> >>>>> So, then, why not put lazy map/filter/reduce/... on Iterator? Thus, >>>>> Brian's >>>>> original serial/lazy example would become: >>>>> >>>>> maxFooWeight = things.iterator() >>>>> .filter(#Thing.isFoo) >>>>> .map(#Thing.getWeight) >>>>> .max(); >>>>> >>>>> or maybe with some less concise but more descriptive (and - purely >>>>> subjectively - "Java-like") names: >>>>> >>>>> maxFooWeight = things.iterator() >>>>> .withFilter(#Thing.isFoo) >>>>> .withTransform(#Thing.getWeight) >>>>> .getLargestValue(); >>>>> >>>>> This has a nice property of working with a more fundamental abstraction >>>>> than >>>>> collections - I can write an Iterator that wraps a non-rewindable I/O >>>>> InputStream, but I cannot write such an Iterable (well, I can - if it >>>>> throws >>>>> after the first call to iterator() - but it will only be usable with >>>>> APIs >>>>> which specify that they only call iterator() on the provided Iterable >>>>> once >>>>> as part of their public contract; otherwise, I'm relying on an >>>>> implementation detail). >>>>> >>>>> The only major annoyance I can see with this approach is that >>>>> enhanced-for-loop only supports Iterables (and arrays) but not >>>>> Iterators, >>>>> and so you'd have to write a manual loop with next()/hasNext() to >>>>> iterate >>>>> over the result. But is there any reason why enhanced-for cannot be >>>>> made to >>>>> support Iterators directly? The only thing it does to the provided >>>>> Iterable >>>>> is to call iterator() on it, and it does it exactly once; it would just >>>>> need >>>>> to use the provided Iterator directly instead. It sounds like it would >>>>> be >>>>> trivial to add. >>>>> >>>>> >>>>> The above didn't touch on what the design would look like for eager or >>>>> lazy/parallel operations. For parallel, the original design can be >>>>> trivially >>>>> adapted by moving asParallel() to Iterator directly, and producing some >>>>> sort >>>>> of ParallelIterator, which is simply a marker interface to enable >>>>> parallelization for all applied operations, but otherwise is the same >>>>> as >>>>> Iterator (probably just extending it). >>>>> >>>>> For eager operations, I would prefer in-place mutating methods >>>>> returning the >>>>> receiver (to permit chaining), with distinct but obviously mapped >>>>> names. For >>>>> example, if Iterator has withFilter(), then Collection would have >>>>> filter(). >>>>> I don't think there is much utility in having eager ops that do a copy, >>>>> and >>>>> even less so for chaining such. I think a simple addition of something >>>>> like >>>>> clone() to Collection (default implementation could do newInstance() >>>>> assuming a no-arg constructor available, and then addAll(this) on that >>>>> new >>>>> instance) would cover vast majority of all cases where you want to get >>>>> a >>>>> copy: the usual pattern would then be to do something like: >>>>> >>>>> Collection getWeights() { >>>>> return things.clone().filter(#Thing.isFoo). >>>>> transform(#Thing.getWeight); >>>>> } >>>>> >>>>> where both filter() and map() operate in-place on the cloned >>>>> collection. >>>>> This also skirts the whole question of the type of the resulting >>>>> collection >>>>> produced by a copying operation - it's clear and unambiguous what it'll >>>>> be >>>>> for clone(), and no other operation makes a copy. >>>>> >>>>> >>>>> On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz >>>>> wrote: >>>>> >>>>> > Since people are already discussing this based on an experimental >>>>> > checkin, let me outline the big picture plan here. >>>>> > >>>>> > The general idea is to add functional-like operations to collections >>>>> -- >>>>> > filter, map, reduce, apply. >>>>> > >>>>> > I see three sensible modes, with explicit choices of which you get. >>>>> > >>>>> > 1. Serial / Eager. This is the straight >>>>> > collections-with-functional-style mode, and some samples have already >>>>> > been checked in as proof of concept. Operations on collections yield >>>>> > new collections, and you can chain the calls. It values ease of use >>>>> > over performance (no new concepts like laziness), but the performance >>>>> > model is still highly predictable. You get things like >>>>> > >>>>> > Collection fooAbles = things.filter( #{ t -> t.isFoo() }); >>>>> > >>>>> > or, with method references: >>>>> > >>>>> > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, >>>>> pretty >>>>> > >>>>> > You can also chain calls together, though you pay a (predictable) >>>>> > performance cost of intermediate collections, which for small >>>>> > collections is unlikely to matter: >>>>> > >>>>> > maxFooWeight = things.filter(#Thing.isFoo) >>>>> > .map(#Thing.getWeight) >>>>> > .max(); >>>>> > >>>>> > The benefit here is concision and clarity. The cost is some >>>>> > performance, but maybe not so much that people freak out. If people >>>>> > care, they move to the next model, which is: >>>>> > >>>>> > 2. Serial / Lazy. Here, the primary abstraction is Stream (name to >>>>> be >>>>> > chosen later, Remi used "lazy" in his example.) To transfer between >>>>> > "eager world" and "lazy world", you use conversion methods (toStream >>>>> / >>>>> > toCollection). A typical call chain probably looks like: >>>>> > collection.toStream / op / op / op / {toCollection,reduce,apply} >>>>> > >>>>> > so the above example becomes >>>>> > >>>>> > maxFooWeight = things.asStream() >>>>> > .filter(#Thing.isFoo) >>>>> > .map(#Thing.getWeight) >>>>> > .max(); >>>>> > >>>>> > The return type of Collection.filter is different from the return >>>>> type >>>>> > of Stream.filter, so the choice and performance costs are reflected >>>>> in >>>>> > the static type system. This avoids the cost of the intermediate >>>>> > collections, but is still serial. If you care about that, you move >>>>> up >>>>> > to the next model, which is: >>>>> > >>>>> > 3. Parallel / Lazy. Here, the primary abstraction is something like >>>>> > ParallelStream or ParallelIterable. Let's call it ParallelFoo to >>>>> avoid >>>>> > bikeshedding for the moment. Now, the code looks like: >>>>> > >>>>> > maxFooWeight = things.asParallelFoo() >>>>> > .filter(#Thing.isFoo) >>>>> > .map(#Thing.getWeight) >>>>> > .max(); >>>>> > >>>>> > Again, the return type of ParallelFoo.filter is different from >>>>> > Stream.filter or Collection.filter, so again the choice is reflected >>>>> in >>>>> > the static type system. But you don't have to rewrite your code. >>>>> > >>>>> > The beauty here is twofold: >>>>> > >>>>> > - The base model (serial/eager) is easy to understand and natural to >>>>> > use as a way of expressing what the programmer wants to do, and >>>>> > attractive enough to stand on its own -- just a little slow with big >>>>> > collections. >>>>> > - Switching between execution models is mostly a matter of adding an >>>>> > explicit conversion or two in the call chain, as the models are >>>>> similar >>>>> > enough that the rest of the code should still work (and even mean the >>>>> > same thing.) >>>>> > >>>>> > >>>>> > On 3/8/2011 8:43 AM, R?mi Forax wrote: >>>>> > > Le 08/03/2011 14:31, Jim Mayer a ?crit : >>>>> > >> // I can tolerate this one >>>>> > >> long product(List list) { >>>>> > >> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> >>>>> sum >>>>> > * x}); >>>>> > >> } >>>>> > > >>>>> > > I prefer this one: >>>>> > > >>>>> > > long product(List list) { >>>>> > > return list.lazy().map(#{x -> (long) x}).reduce(0L, >>>>> #{sum, x -> >>>>> > sum * x}); >>>>> > > } >>>>> > > >>>>> > > lazy() means, don't do map directly, but wait and do map and reduce >>>>> in >>>>> > > one iteration. >>>>> > > >>>>> > > R?mi >>>>> > > >>>>> > > >>>>> > >>>>> > >>>>> >>>>> >>>> >>> >> > From neal at gafter.com Sun Mar 13 09:37:06 2011 From: neal at gafter.com (Neal Gafter) Date: Sun, 13 Mar 2011 09:37:06 -0700 Subject: Design for collections upgrades In-Reply-To: <4D7923E6.1010601@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7923E6.1010601@oracle.com> Message-ID: I suggest that in-place operations, if included, should be named something like void Collection.retainAll(Predicate predicate); void Collection.removeAll(Predicate predicate); I think this naming would remove confusion vs the other aggregate operations. As for the bulk data operations that do not modify the input collection, making them lazy and providing toArray, toList, toSet etc eager operations solves many issues, including what kind of collection to build and how to reduce user confusion arising from the existence of related but semantically distinct eager/lazy APIs. I don't think we need toStream or it's ilk, as collection and Iterable are already stream types. I do believe we need toParallel to enter a realm where the operations, while still lazy, will be done using concurrency on the final reduce/toArray/toList/etc. Finally, I should point out to the language designers out there that these APIs can be structured as a monad, not because we want programmers to think of them as such but because it provides great flexibility in clients wanting to port or reuse code from one computational domain to another. Some expert familiar with such techniques should take a more firm role influencing the shape of these APIs. I don't know who is on the expert group so I can't recommend anyone in particular. Cheers, Neal From jim at pentastich.org Sun Mar 13 09:38:00 2011 From: jim at pentastich.org (Jim Mayer) Date: Sun, 13 Mar 2011 12:38:00 -0400 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: I have a different take on this. Non-reusable streams (e.g., Iterator, not Iterable) can be used to represent data structures that cannot be easily regenerated. Infinite series come to mind, as well as data sets that are very large or come from non-determinate sources. Since lazily evaluated streams can represent these gracefully and collections cannot (what do you return for the size of a infinte series?), why cripple the stream abstraction by tying it to collections? On the other hand, if a stream is backed by a collection, one can simply call "asStream()" again to get a "rewound" series. So, instead of using Iterable, I'd prefer something like this: (1) Collections sport an "asStream" (or even the existing "iterator()" method, if Iterator turns out to be flexible enough). (2) That whatever class/interface is the result of "asStream" support an API for creating instances outside of the Collections framework (note that Iterator already does this). (3) That we consider making one of the operators something that can "truncate" an infinite series. With this kind of framework one could have the same kind of thing we've been talking about: int sum(Collection s) { return s.asStream().fold(#{sum, x -> sum + x}, 0); } but could also have: int sum(BufferedReader r) { return r.asStream(r#readLine).map(Integer#valueOf).fold(#{sum, x-> sum + x}, 0); } or even: int sum(StreamTypeThing s, int count) { return s.prefix(count).fold(#{sum, x -> sum + x}, 0); } As a side note, I agree with one of the earlier posters that if we did something like this we'd want to allow stuff like: for (String x : c.asStream().map(...)) {} -- Jim On Sat, Mar 12, 2011 at 11:37 PM, Colin Decker wrote: > Because there's no need to and because Iterables (being reusable) are far > more flexible than Iterators. The Iterable interface is just as lazy as > Iterator. The Stream interface should be Iterable. > > -- > Colin > > > On Sat, Mar 12, 2011 at 11:08 PM, Pavel Minaev wrote: > > > I'm curious as to why you think that limiting lazy operations to > iterators > > (or streams - the name is immaterial) is undesirable? In terms of code, > it > > is exactly the same as the proposal which started the thread, with a need > > for one extra method call - iterator() rather than asStream() - on the > > collection, before you are in the lazy land. In terms of semantics, it > > avoids introduction of new abstractions where existing ones are > sufficient > > to capture the intent (iterators are inherently lazy). > > > > On Sat, Mar 12, 2011 at 7:53 PM, Colin Decker > wrote: > > > >> I don't feel like a comparison to InputStream etc. makes much sense > >> considering "Stream" is an arbitrary name that can easily be changed to > >> something more appropriate ("Streamable", say). I also think it's a > weakness > >> of the IO streams that they don't have an Iterable equivalent (like > >> InputSupplier from Guava). Regardless, limiting lazy filter/map to > Iterator > >> would be... undesirable. I do think Iterator should have such methods as > >> well, though. > >> > >> -- > >> Colin > >> > >> > >> > >> On Sat, Mar 12, 2011 at 8:30 PM, Pavel Minaev wrote: > >> > >>> I've been re-reading the "Design for collection upgrades" thread, and > had > >>> some thoughts on the nature of the Stream abstraction (for lazy/serial > >>> scenario) as originally outlined in Brian's post that kicked off the > >>> thread, > >>> and users expectations of what comes with that name. > >>> > >>> Per the proposal, it sounds like Stream is more or less a marker > >>> interface > >>> to indicate lazy operations, and not otherwise any different from > >>> Iterable. > >>> However, this isn't what "stream" has historically meant in imperative > >>> PLs > >>> and their frameworks. For some examples of what I mean, let me point at > >>> java.io.InputStream, or at C++ std::basic_istream. In both cases, the > >>> fundamental property of the streams - the one that is guaranteed to be > >>> supported by _any_ stream - is that you can read elements. InputStream > >>> also > >>> offers mark()/reset(), but those are conditionally supported, and so > are > >>> not > >>> part of the basic contract of the abstraction; they could (one could > even > >>> argue that, from a pure OOD approach, they should) just as well be > moved > >>> to > >>> a more concrete interface that could be queried by clients instead of > >>> using > >>> markSupported(). > >>> > >>> The important thing with that basic contract is that once a value is > read > >>> from a stream, it stays read: a stream by itself is a read-once > sequence. > >>> There may be ways to obtain another stream that would re-read the same > >>> exact > >>> elements, but that would still be a new stream object. For streams that > >>> wrap > >>> some data store (e.g. FileInputStream or ByteArrayInputStream), the > >>> stream > >>> object is essentially a cursor into the store - it has a current > >>> position, > >>> which every read advances towards the end of the store. Furthermore, > the > >>> stream is not _the_ store - you can have several FileInputStreams over > >>> the > >>> same file, or several ByteArrayInputStreams sharing the same byte > array. > >>> > >>> Now if we take the above and see how it applies to collections, it > >>> actually > >>> is a very familiar concept: something that is not a collection itself, > >>> but > >>> is a forward-only cursor for a collection, and each collection may have > >>> more > >>> than one such cursor - why, that is Iterator. Its next() and hasNext() > >>> methods match exactly the basic input stream contract; remove() does > not, > >>> but it is conditionally-supported anyway. An analogy to highlight this > >>> point: Iterator is to Iterable/Collection what ByteArrayInputStream is > to > >>> byte array. > >>> > >>> Iterators, being cursors, are also naturally expected to be lazy by API > >>> clients - if I provide a method that takes an iterator, applies a > filter > >>> to > >>> it, and returns another iterator as a result, no-one would expect > >>> filtering > >>> to occur over the entire collection right there and then. It's clear > that > >>> the result of such operation is a "filtered iterator", that would apply > >>> the > >>> filter as it is being iterated. > >>> > >>> So, then, why not put lazy map/filter/reduce/... on Iterator? Thus, > >>> Brian's > >>> original serial/lazy example would become: > >>> > >>> maxFooWeight = things.iterator() > >>> .filter(#Thing.isFoo) > >>> .map(#Thing.getWeight) > >>> .max(); > >>> > >>> or maybe with some less concise but more descriptive (and - purely > >>> subjectively - "Java-like") names: > >>> > >>> maxFooWeight = things.iterator() > >>> .withFilter(#Thing.isFoo) > >>> .withTransform(#Thing.getWeight) > >>> .getLargestValue(); > >>> > >>> This has a nice property of working with a more fundamental abstraction > >>> than > >>> collections - I can write an Iterator that wraps a non-rewindable I/O > >>> InputStream, but I cannot write such an Iterable (well, I can - if it > >>> throws > >>> after the first call to iterator() - but it will only be usable with > APIs > >>> which specify that they only call iterator() on the provided Iterable > >>> once > >>> as part of their public contract; otherwise, I'm relying on an > >>> implementation detail). > >>> > >>> The only major annoyance I can see with this approach is that > >>> enhanced-for-loop only supports Iterables (and arrays) but not > Iterators, > >>> and so you'd have to write a manual loop with next()/hasNext() to > iterate > >>> over the result. But is there any reason why enhanced-for cannot be > made > >>> to > >>> support Iterators directly? The only thing it does to the provided > >>> Iterable > >>> is to call iterator() on it, and it does it exactly once; it would just > >>> need > >>> to use the provided Iterator directly instead. It sounds like it would > be > >>> trivial to add. > >>> > >>> > >>> The above didn't touch on what the design would look like for eager or > >>> lazy/parallel operations. For parallel, the original design can be > >>> trivially > >>> adapted by moving asParallel() to Iterator directly, and producing some > >>> sort > >>> of ParallelIterator, which is simply a marker interface to enable > >>> parallelization for all applied operations, but otherwise is the same > as > >>> Iterator (probably just extending it). > >>> > >>> For eager operations, I would prefer in-place mutating methods > returning > >>> the > >>> receiver (to permit chaining), with distinct but obviously mapped > names. > >>> For > >>> example, if Iterator has withFilter(), then Collection would have > >>> filter(). > >>> I don't think there is much utility in having eager ops that do a copy, > >>> and > >>> even less so for chaining such. I think a simple addition of something > >>> like > >>> clone() to Collection (default implementation could do newInstance() > >>> assuming a no-arg constructor available, and then addAll(this) on that > >>> new > >>> instance) would cover vast majority of all cases where you want to get > a > >>> copy: the usual pattern would then be to do something like: > >>> > >>> Collection getWeights() { > >>> return things.clone().filter(#Thing.isFoo). > >>> transform(#Thing.getWeight); > >>> } > >>> > >>> where both filter() and map() operate in-place on the cloned > collection. > >>> This also skirts the whole question of the type of the resulting > >>> collection > >>> produced by a copying operation - it's clear and unambiguous what it'll > >>> be > >>> for clone(), and no other operation makes a copy. > >>> > >>> > >>> On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz > >>> wrote: > >>> > >>> > Since people are already discussing this based on an experimental > >>> > checkin, let me outline the big picture plan here. > >>> > > >>> > The general idea is to add functional-like operations to collections > -- > >>> > filter, map, reduce, apply. > >>> > > >>> > I see three sensible modes, with explicit choices of which you get. > >>> > > >>> > 1. Serial / Eager. This is the straight > >>> > collections-with-functional-style mode, and some samples have already > >>> > been checked in as proof of concept. Operations on collections yield > >>> > new collections, and you can chain the calls. It values ease of use > >>> > over performance (no new concepts like laziness), but the performance > >>> > model is still highly predictable. You get things like > >>> > > >>> > Collection fooAbles = things.filter( #{ t -> t.isFoo() }); > >>> > > >>> > or, with method references: > >>> > > >>> > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, > pretty > >>> > > >>> > You can also chain calls together, though you pay a (predictable) > >>> > performance cost of intermediate collections, which for small > >>> > collections is unlikely to matter: > >>> > > >>> > maxFooWeight = things.filter(#Thing.isFoo) > >>> > .map(#Thing.getWeight) > >>> > .max(); > >>> > > >>> > The benefit here is concision and clarity. The cost is some > >>> > performance, but maybe not so much that people freak out. If people > >>> > care, they move to the next model, which is: > >>> > > >>> > 2. Serial / Lazy. Here, the primary abstraction is Stream (name to > be > >>> > chosen later, Remi used "lazy" in his example.) To transfer between > >>> > "eager world" and "lazy world", you use conversion methods (toStream > / > >>> > toCollection). A typical call chain probably looks like: > >>> > collection.toStream / op / op / op / {toCollection,reduce,apply} > >>> > > >>> > so the above example becomes > >>> > > >>> > maxFooWeight = things.asStream() > >>> > .filter(#Thing.isFoo) > >>> > .map(#Thing.getWeight) > >>> > .max(); > >>> > > >>> > The return type of Collection.filter is different from the return > type > >>> > of Stream.filter, so the choice and performance costs are reflected > in > >>> > the static type system. This avoids the cost of the intermediate > >>> > collections, but is still serial. If you care about that, you move > up > >>> > to the next model, which is: > >>> > > >>> > 3. Parallel / Lazy. Here, the primary abstraction is something like > >>> > ParallelStream or ParallelIterable. Let's call it ParallelFoo to > avoid > >>> > bikeshedding for the moment. Now, the code looks like: > >>> > > >>> > maxFooWeight = things.asParallelFoo() > >>> > .filter(#Thing.isFoo) > >>> > .map(#Thing.getWeight) > >>> > .max(); > >>> > > >>> > Again, the return type of ParallelFoo.filter is different from > >>> > Stream.filter or Collection.filter, so again the choice is reflected > in > >>> > the static type system. But you don't have to rewrite your code. > >>> > > >>> > The beauty here is twofold: > >>> > > >>> > - The base model (serial/eager) is easy to understand and natural to > >>> > use as a way of expressing what the programmer wants to do, and > >>> > attractive enough to stand on its own -- just a little slow with big > >>> > collections. > >>> > - Switching between execution models is mostly a matter of adding an > >>> > explicit conversion or two in the call chain, as the models are > similar > >>> > enough that the rest of the code should still work (and even mean the > >>> > same thing.) > >>> > > >>> > > >>> > On 3/8/2011 8:43 AM, R?mi Forax wrote: > >>> > > Le 08/03/2011 14:31, Jim Mayer a ?crit : > >>> > >> // I can tolerate this one > >>> > >> long product(List list) { > >>> > >> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x -> > >>> sum > >>> > * x}); > >>> > >> } > >>> > > > >>> > > I prefer this one: > >>> > > > >>> > > long product(List list) { > >>> > > return list.lazy().map(#{x -> (long) x}).reduce(0L, > #{sum, > >>> x -> > >>> > sum * x}); > >>> > > } > >>> > > > >>> > > lazy() means, don't do map directly, but wait and do map and reduce > >>> in > >>> > > one iteration. > >>> > > > >>> > > R?mi > >>> > > > >>> > > > >>> > > >>> > > >>> > >>> > >> > > > > From cgdecker at gmail.com Sun Mar 13 10:09:48 2011 From: cgdecker at gmail.com (Colin Decker) Date: Sun, 13 Mar 2011 13:09:48 -0400 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: Iterable can represent an infinite series or a very large data set just as well as Iterator, given that it is just a factory for Iterators... it isn't tied to Collections. Obviously there are some cases where you just want an Iterator, and there's no reason that lazy filtering, mapping, etc. can't be done on an Iterator as well. -- Colin On Sun, Mar 13, 2011 at 12:38 PM, Jim Mayer wrote: > I have a different take on this. Non-reusable streams (e.g., Iterator, not > Iterable) can be used to represent data structures that cannot be easily > regenerated. Infinite series come to mind, as well as data sets that are > very large or come from non-determinate sources. Since lazily evaluated > streams can represent these gracefully and collections cannot (what do you > return for the size of a infinte series?), why cripple the stream > abstraction by tying it to collections? On the other hand, if a stream is > backed by a collection, one can simply call "asStream()" again to get a > "rewound" series. > > So, instead of using Iterable, I'd prefer something like this: > > (1) Collections sport an "asStream" (or even the existing "iterator()" > method, if Iterator turns out to be flexible enough). > (2) That whatever class/interface is the result of "asStream" support an > API for creating instances outside of the Collections framework (note that > Iterator already does this). > (3) That we consider making one of the operators something that can > "truncate" an infinite series. > > With this kind of framework one could have the same kind of thing we've > been talking about: > > int sum(Collection s) { > return s.asStream().fold(#{sum, x -> sum + x}, 0); > } > > but could also have: > > int sum(BufferedReader r) { > return r.asStream(r#readLine).map(Integer#valueOf).fold(#{sum, x-> > sum + x}, 0); > } > > or even: > > int sum(StreamTypeThing s, int count) { > return s.prefix(count).fold(#{sum, x -> sum + x}, 0); > } > > As a side note, I agree with one of the earlier posters that if we did > something like this we'd want to allow stuff like: > > for (String x : c.asStream().map(...)) {} > > -- Jim > > On Sat, Mar 12, 2011 at 11:37 PM, Colin Decker wrote: > >> Because there's no need to and because Iterables (being reusable) are far >> more flexible than Iterators. The Iterable interface is just as lazy as >> Iterator. The Stream interface should be Iterable. >> >> -- >> Colin >> >> >> On Sat, Mar 12, 2011 at 11:08 PM, Pavel Minaev wrote: >> >> > I'm curious as to why you think that limiting lazy operations to >> iterators >> > (or streams - the name is immaterial) is undesirable? In terms of code, >> it >> > is exactly the same as the proposal which started the thread, with a >> need >> > for one extra method call - iterator() rather than asStream() - on the >> > collection, before you are in the lazy land. In terms of semantics, it >> > avoids introduction of new abstractions where existing ones are >> sufficient >> > to capture the intent (iterators are inherently lazy). >> > >> > On Sat, Mar 12, 2011 at 7:53 PM, Colin Decker >> wrote: >> > >> >> I don't feel like a comparison to InputStream etc. makes much sense >> >> considering "Stream" is an arbitrary name that can easily be changed to >> >> something more appropriate ("Streamable", say). I also think it's a >> weakness >> >> of the IO streams that they don't have an Iterable equivalent (like >> >> InputSupplier from Guava). Regardless, limiting lazy filter/map to >> Iterator >> >> would be... undesirable. I do think Iterator should have such methods >> as >> >> well, though. >> >> >> >> -- >> >> Colin >> >> >> >> >> >> >> >> On Sat, Mar 12, 2011 at 8:30 PM, Pavel Minaev >> wrote: >> >> >> >>> I've been re-reading the "Design for collection upgrades" thread, and >> had >> >>> some thoughts on the nature of the Stream abstraction (for lazy/serial >> >>> scenario) as originally outlined in Brian's post that kicked off the >> >>> thread, >> >>> and users expectations of what comes with that name. >> >>> >> >>> Per the proposal, it sounds like Stream is more or less a marker >> >>> interface >> >>> to indicate lazy operations, and not otherwise any different from >> >>> Iterable. >> >>> However, this isn't what "stream" has historically meant in imperative >> >>> PLs >> >>> and their frameworks. For some examples of what I mean, let me point >> at >> >>> java.io.InputStream, or at C++ std::basic_istream. In both cases, the >> >>> fundamental property of the streams - the one that is guaranteed to be >> >>> supported by _any_ stream - is that you can read elements. InputStream >> >>> also >> >>> offers mark()/reset(), but those are conditionally supported, and so >> are >> >>> not >> >>> part of the basic contract of the abstraction; they could (one could >> even >> >>> argue that, from a pure OOD approach, they should) just as well be >> moved >> >>> to >> >>> a more concrete interface that could be queried by clients instead of >> >>> using >> >>> markSupported(). >> >>> >> >>> The important thing with that basic contract is that once a value is >> read >> >>> from a stream, it stays read: a stream by itself is a read-once >> sequence. >> >>> There may be ways to obtain another stream that would re-read the same >> >>> exact >> >>> elements, but that would still be a new stream object. For streams >> that >> >>> wrap >> >>> some data store (e.g. FileInputStream or ByteArrayInputStream), the >> >>> stream >> >>> object is essentially a cursor into the store - it has a current >> >>> position, >> >>> which every read advances towards the end of the store. Furthermore, >> the >> >>> stream is not _the_ store - you can have several FileInputStreams over >> >>> the >> >>> same file, or several ByteArrayInputStreams sharing the same byte >> array. >> >>> >> >>> Now if we take the above and see how it applies to collections, it >> >>> actually >> >>> is a very familiar concept: something that is not a collection itself, >> >>> but >> >>> is a forward-only cursor for a collection, and each collection may >> have >> >>> more >> >>> than one such cursor - why, that is Iterator. Its next() and hasNext() >> >>> methods match exactly the basic input stream contract; remove() does >> not, >> >>> but it is conditionally-supported anyway. An analogy to highlight this >> >>> point: Iterator is to Iterable/Collection what ByteArrayInputStream is >> to >> >>> byte array. >> >>> >> >>> Iterators, being cursors, are also naturally expected to be lazy by >> API >> >>> clients - if I provide a method that takes an iterator, applies a >> filter >> >>> to >> >>> it, and returns another iterator as a result, no-one would expect >> >>> filtering >> >>> to occur over the entire collection right there and then. It's clear >> that >> >>> the result of such operation is a "filtered iterator", that would >> apply >> >>> the >> >>> filter as it is being iterated. >> >>> >> >>> So, then, why not put lazy map/filter/reduce/... on Iterator? Thus, >> >>> Brian's >> >>> original serial/lazy example would become: >> >>> >> >>> maxFooWeight = things.iterator() >> >>> .filter(#Thing.isFoo) >> >>> .map(#Thing.getWeight) >> >>> .max(); >> >>> >> >>> or maybe with some less concise but more descriptive (and - purely >> >>> subjectively - "Java-like") names: >> >>> >> >>> maxFooWeight = things.iterator() >> >>> .withFilter(#Thing.isFoo) >> >>> .withTransform(#Thing.getWeight) >> >>> .getLargestValue(); >> >>> >> >>> This has a nice property of working with a more fundamental >> abstraction >> >>> than >> >>> collections - I can write an Iterator that wraps a non-rewindable I/O >> >>> InputStream, but I cannot write such an Iterable (well, I can - if it >> >>> throws >> >>> after the first call to iterator() - but it will only be usable with >> APIs >> >>> which specify that they only call iterator() on the provided Iterable >> >>> once >> >>> as part of their public contract; otherwise, I'm relying on an >> >>> implementation detail). >> >>> >> >>> The only major annoyance I can see with this approach is that >> >>> enhanced-for-loop only supports Iterables (and arrays) but not >> Iterators, >> >>> and so you'd have to write a manual loop with next()/hasNext() to >> iterate >> >>> over the result. But is there any reason why enhanced-for cannot be >> made >> >>> to >> >>> support Iterators directly? The only thing it does to the provided >> >>> Iterable >> >>> is to call iterator() on it, and it does it exactly once; it would >> just >> >>> need >> >>> to use the provided Iterator directly instead. It sounds like it would >> be >> >>> trivial to add. >> >>> >> >>> >> >>> The above didn't touch on what the design would look like for eager or >> >>> lazy/parallel operations. For parallel, the original design can be >> >>> trivially >> >>> adapted by moving asParallel() to Iterator directly, and producing >> some >> >>> sort >> >>> of ParallelIterator, which is simply a marker interface to enable >> >>> parallelization for all applied operations, but otherwise is the same >> as >> >>> Iterator (probably just extending it). >> >>> >> >>> For eager operations, I would prefer in-place mutating methods >> returning >> >>> the >> >>> receiver (to permit chaining), with distinct but obviously mapped >> names. >> >>> For >> >>> example, if Iterator has withFilter(), then Collection would have >> >>> filter(). >> >>> I don't think there is much utility in having eager ops that do a >> copy, >> >>> and >> >>> even less so for chaining such. I think a simple addition of something >> >>> like >> >>> clone() to Collection (default implementation could do newInstance() >> >>> assuming a no-arg constructor available, and then addAll(this) on that >> >>> new >> >>> instance) would cover vast majority of all cases where you want to get >> a >> >>> copy: the usual pattern would then be to do something like: >> >>> >> >>> Collection getWeights() { >> >>> return things.clone().filter(#Thing.isFoo). >> >>> transform(#Thing.getWeight); >> >>> } >> >>> >> >>> where both filter() and map() operate in-place on the cloned >> collection. >> >>> This also skirts the whole question of the type of the resulting >> >>> collection >> >>> produced by a copying operation - it's clear and unambiguous what >> it'll >> >>> be >> >>> for clone(), and no other operation makes a copy. >> >>> >> >>> >> >>> On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz >> >>> wrote: >> >>> >> >>> > Since people are already discussing this based on an experimental >> >>> > checkin, let me outline the big picture plan here. >> >>> > >> >>> > The general idea is to add functional-like operations to collections >> -- >> >>> > filter, map, reduce, apply. >> >>> > >> >>> > I see three sensible modes, with explicit choices of which you get. >> >>> > >> >>> > 1. Serial / Eager. This is the straight >> >>> > collections-with-functional-style mode, and some samples have >> already >> >>> > been checked in as proof of concept. Operations on collections >> yield >> >>> > new collections, and you can chain the calls. It values ease of use >> >>> > over performance (no new concepts like laziness), but the >> performance >> >>> > model is still highly predictable. You get things like >> >>> > >> >>> > Collection fooAbles = things.filter( #{ t -> t.isFoo() }); >> >>> > >> >>> > or, with method references: >> >>> > >> >>> > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, >> pretty >> >>> > >> >>> > You can also chain calls together, though you pay a (predictable) >> >>> > performance cost of intermediate collections, which for small >> >>> > collections is unlikely to matter: >> >>> > >> >>> > maxFooWeight = things.filter(#Thing.isFoo) >> >>> > .map(#Thing.getWeight) >> >>> > .max(); >> >>> > >> >>> > The benefit here is concision and clarity. The cost is some >> >>> > performance, but maybe not so much that people freak out. If people >> >>> > care, they move to the next model, which is: >> >>> > >> >>> > 2. Serial / Lazy. Here, the primary abstraction is Stream (name to >> be >> >>> > chosen later, Remi used "lazy" in his example.) To transfer between >> >>> > "eager world" and "lazy world", you use conversion methods (toStream >> / >> >>> > toCollection). A typical call chain probably looks like: >> >>> > collection.toStream / op / op / op / {toCollection,reduce,apply} >> >>> > >> >>> > so the above example becomes >> >>> > >> >>> > maxFooWeight = things.asStream() >> >>> > .filter(#Thing.isFoo) >> >>> > .map(#Thing.getWeight) >> >>> > .max(); >> >>> > >> >>> > The return type of Collection.filter is different from the return >> type >> >>> > of Stream.filter, so the choice and performance costs are reflected >> in >> >>> > the static type system. This avoids the cost of the intermediate >> >>> > collections, but is still serial. If you care about that, you move >> up >> >>> > to the next model, which is: >> >>> > >> >>> > 3. Parallel / Lazy. Here, the primary abstraction is something >> like >> >>> > ParallelStream or ParallelIterable. Let's call it ParallelFoo to >> avoid >> >>> > bikeshedding for the moment. Now, the code looks like: >> >>> > >> >>> > maxFooWeight = things.asParallelFoo() >> >>> > .filter(#Thing.isFoo) >> >>> > .map(#Thing.getWeight) >> >>> > .max(); >> >>> > >> >>> > Again, the return type of ParallelFoo.filter is different from >> >>> > Stream.filter or Collection.filter, so again the choice is reflected >> in >> >>> > the static type system. But you don't have to rewrite your code. >> >>> > >> >>> > The beauty here is twofold: >> >>> > >> >>> > - The base model (serial/eager) is easy to understand and natural >> to >> >>> > use as a way of expressing what the programmer wants to do, and >> >>> > attractive enough to stand on its own -- just a little slow with big >> >>> > collections. >> >>> > - Switching between execution models is mostly a matter of adding >> an >> >>> > explicit conversion or two in the call chain, as the models are >> similar >> >>> > enough that the rest of the code should still work (and even mean >> the >> >>> > same thing.) >> >>> > >> >>> > >> >>> > On 3/8/2011 8:43 AM, R?mi Forax wrote: >> >>> > > Le 08/03/2011 14:31, Jim Mayer a ?crit : >> >>> > >> // I can tolerate this one >> >>> > >> long product(List list) { >> >>> > >> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x >> -> >> >>> sum >> >>> > * x}); >> >>> > >> } >> >>> > > >> >>> > > I prefer this one: >> >>> > > >> >>> > > long product(List list) { >> >>> > > return list.lazy().map(#{x -> (long) x}).reduce(0L, >> #{sum, >> >>> x -> >> >>> > sum * x}); >> >>> > > } >> >>> > > >> >>> > > lazy() means, don't do map directly, but wait and do map and >> reduce >> >>> in >> >>> > > one iteration. >> >>> > > >> >>> > > R?mi >> >>> > > >> >>> > > >> >>> > >> >>> > >> >>> >> >>> >> >> >> > >> >> > From brian.goetz at oracle.com Sun Mar 13 10:20:02 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 13 Mar 2011 13:20:02 -0400 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7923E6.1010601@oracle.com> Message-ID: <4D7CFCC2.6060209@oracle.com> > I suggest that in-place operations, if included, should be named something like > > void Collection.retainAll(Predicate predicate); > void Collection.removeAll(Predicate predicate); Which, conveniently, coincides exactly with our intent. Map and reduce do not make sense as in-place operations, so really the whole in-place thing is about filtering, for which we already have sensible names (retainAll/removeAll) that are just crying out for lambda versions. The bigger issues seem to be: - Explicit Stream abstraction vs adapting Iterable / Iterator - Whether streams should be reusable (Iterable) or not (Iterator) - Whether eager operations are desirable or needed at all - Whether an explicit toStream method is needed, or whether it is acceptable to add new lazy operations to collections (interacts with above question about eagerness) > Finally, I should point out to the language designers out there that > these APIs can be structured as a monad, not because we want > programmers to think of them as such but because it provides great > flexibility in clients wanting to port or reuse code from one > computational domain to another. Some expert familiar with such > techniques should take a more firm role influencing the shape of these > APIs. I don't know who is on the expert group so I can't recommend > anyone in particular. The conclusion in this last sentence doesn't make sense. You can certainly recommend someone; if by some chance that person happens to be on the EG already, then your recommendation degenerates into a mere note of approval. From jim at pentastich.org Sun Mar 13 10:24:49 2011 From: jim at pentastich.org (Jim Mayer) Date: Sun, 13 Mar 2011 13:24:49 -0400 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: Yes, you can "do" that with an iterable, but I don't like the idea of an iterable that can only be used once. Most, if not all, classes that implement Iterable today have the property that you can call 'iterator' multiple times to get independent iterators. -- Jim On Sun, Mar 13, 2011 at 1:09 PM, Colin Decker wrote: > Iterable can represent an infinite series or a very large data set just as > well as Iterator, given that it is just a factory for Iterators... it isn't > tied to Collections. Obviously there are some cases where you just want an > Iterator, and there's no reason that lazy filtering, mapping, etc. can't be > done on an Iterator as well. > > -- > Colin > > > > On Sun, Mar 13, 2011 at 12:38 PM, Jim Mayer wrote: > >> I have a different take on this. Non-reusable streams (e.g., Iterator, >> not Iterable) can be used to represent data structures that cannot be easily >> regenerated. Infinite series come to mind, as well as data sets that are >> very large or come from non-determinate sources. Since lazily evaluated >> streams can represent these gracefully and collections cannot (what do you >> return for the size of a infinte series?), why cripple the stream >> abstraction by tying it to collections? On the other hand, if a stream is >> backed by a collection, one can simply call "asStream()" again to get a >> "rewound" series. >> >> So, instead of using Iterable, I'd prefer something like this: >> >> (1) Collections sport an "asStream" (or even the existing "iterator()" >> method, if Iterator turns out to be flexible enough). >> (2) That whatever class/interface is the result of "asStream" support an >> API for creating instances outside of the Collections framework (note that >> Iterator already does this). >> (3) That we consider making one of the operators something that can >> "truncate" an infinite series. >> >> With this kind of framework one could have the same kind of thing we've >> been talking about: >> >> int sum(Collection s) { >> return s.asStream().fold(#{sum, x -> sum + x}, 0); >> } >> >> but could also have: >> >> int sum(BufferedReader r) { >> return r.asStream(r#readLine).map(Integer#valueOf).fold(#{sum, x-> >> sum + x}, 0); >> } >> >> or even: >> >> int sum(StreamTypeThing s, int count) { >> return s.prefix(count).fold(#{sum, x -> sum + x}, 0); >> } >> >> As a side note, I agree with one of the earlier posters that if we did >> something like this we'd want to allow stuff like: >> >> for (String x : c.asStream().map(...)) {} >> >> -- Jim >> >> On Sat, Mar 12, 2011 at 11:37 PM, Colin Decker wrote: >> >>> Because there's no need to and because Iterables (being reusable) are far >>> more flexible than Iterators. The Iterable interface is just as lazy as >>> Iterator. The Stream interface should be Iterable. >>> >>> -- >>> Colin >>> >>> >>> On Sat, Mar 12, 2011 at 11:08 PM, Pavel Minaev wrote: >>> >>> > I'm curious as to why you think that limiting lazy operations to >>> iterators >>> > (or streams - the name is immaterial) is undesirable? In terms of code, >>> it >>> > is exactly the same as the proposal which started the thread, with a >>> need >>> > for one extra method call - iterator() rather than asStream() - on the >>> > collection, before you are in the lazy land. In terms of semantics, it >>> > avoids introduction of new abstractions where existing ones are >>> sufficient >>> > to capture the intent (iterators are inherently lazy). >>> > >>> > On Sat, Mar 12, 2011 at 7:53 PM, Colin Decker >>> wrote: >>> > >>> >> I don't feel like a comparison to InputStream etc. makes much sense >>> >> considering "Stream" is an arbitrary name that can easily be changed >>> to >>> >> something more appropriate ("Streamable", say). I also think it's a >>> weakness >>> >> of the IO streams that they don't have an Iterable equivalent (like >>> >> InputSupplier from Guava). Regardless, limiting lazy filter/map to >>> Iterator >>> >> would be... undesirable. I do think Iterator should have such methods >>> as >>> >> well, though. >>> >> >>> >> -- >>> >> Colin >>> >> >>> >> >>> >> >>> >> On Sat, Mar 12, 2011 at 8:30 PM, Pavel Minaev >>> wrote: >>> >> >>> >>> I've been re-reading the "Design for collection upgrades" thread, and >>> had >>> >>> some thoughts on the nature of the Stream abstraction (for >>> lazy/serial >>> >>> scenario) as originally outlined in Brian's post that kicked off the >>> >>> thread, >>> >>> and users expectations of what comes with that name. >>> >>> >>> >>> Per the proposal, it sounds like Stream is more or less a marker >>> >>> interface >>> >>> to indicate lazy operations, and not otherwise any different from >>> >>> Iterable. >>> >>> However, this isn't what "stream" has historically meant in >>> imperative >>> >>> PLs >>> >>> and their frameworks. For some examples of what I mean, let me point >>> at >>> >>> java.io.InputStream, or at C++ std::basic_istream. In both cases, the >>> >>> fundamental property of the streams - the one that is guaranteed to >>> be >>> >>> supported by _any_ stream - is that you can read elements. >>> InputStream >>> >>> also >>> >>> offers mark()/reset(), but those are conditionally supported, and so >>> are >>> >>> not >>> >>> part of the basic contract of the abstraction; they could (one could >>> even >>> >>> argue that, from a pure OOD approach, they should) just as well be >>> moved >>> >>> to >>> >>> a more concrete interface that could be queried by clients instead of >>> >>> using >>> >>> markSupported(). >>> >>> >>> >>> The important thing with that basic contract is that once a value is >>> read >>> >>> from a stream, it stays read: a stream by itself is a read-once >>> sequence. >>> >>> There may be ways to obtain another stream that would re-read the >>> same >>> >>> exact >>> >>> elements, but that would still be a new stream object. For streams >>> that >>> >>> wrap >>> >>> some data store (e.g. FileInputStream or ByteArrayInputStream), the >>> >>> stream >>> >>> object is essentially a cursor into the store - it has a current >>> >>> position, >>> >>> which every read advances towards the end of the store. Furthermore, >>> the >>> >>> stream is not _the_ store - you can have several FileInputStreams >>> over >>> >>> the >>> >>> same file, or several ByteArrayInputStreams sharing the same byte >>> array. >>> >>> >>> >>> Now if we take the above and see how it applies to collections, it >>> >>> actually >>> >>> is a very familiar concept: something that is not a collection >>> itself, >>> >>> but >>> >>> is a forward-only cursor for a collection, and each collection may >>> have >>> >>> more >>> >>> than one such cursor - why, that is Iterator. Its next() and >>> hasNext() >>> >>> methods match exactly the basic input stream contract; remove() does >>> not, >>> >>> but it is conditionally-supported anyway. An analogy to highlight >>> this >>> >>> point: Iterator is to Iterable/Collection what ByteArrayInputStream >>> is to >>> >>> byte array. >>> >>> >>> >>> Iterators, being cursors, are also naturally expected to be lazy by >>> API >>> >>> clients - if I provide a method that takes an iterator, applies a >>> filter >>> >>> to >>> >>> it, and returns another iterator as a result, no-one would expect >>> >>> filtering >>> >>> to occur over the entire collection right there and then. It's clear >>> that >>> >>> the result of such operation is a "filtered iterator", that would >>> apply >>> >>> the >>> >>> filter as it is being iterated. >>> >>> >>> >>> So, then, why not put lazy map/filter/reduce/... on Iterator? Thus, >>> >>> Brian's >>> >>> original serial/lazy example would become: >>> >>> >>> >>> maxFooWeight = things.iterator() >>> >>> .filter(#Thing.isFoo) >>> >>> .map(#Thing.getWeight) >>> >>> .max(); >>> >>> >>> >>> or maybe with some less concise but more descriptive (and - purely >>> >>> subjectively - "Java-like") names: >>> >>> >>> >>> maxFooWeight = things.iterator() >>> >>> .withFilter(#Thing.isFoo) >>> >>> .withTransform(#Thing.getWeight) >>> >>> .getLargestValue(); >>> >>> >>> >>> This has a nice property of working with a more fundamental >>> abstraction >>> >>> than >>> >>> collections - I can write an Iterator that wraps a non-rewindable I/O >>> >>> InputStream, but I cannot write such an Iterable (well, I can - if it >>> >>> throws >>> >>> after the first call to iterator() - but it will only be usable with >>> APIs >>> >>> which specify that they only call iterator() on the provided Iterable >>> >>> once >>> >>> as part of their public contract; otherwise, I'm relying on an >>> >>> implementation detail). >>> >>> >>> >>> The only major annoyance I can see with this approach is that >>> >>> enhanced-for-loop only supports Iterables (and arrays) but not >>> Iterators, >>> >>> and so you'd have to write a manual loop with next()/hasNext() to >>> iterate >>> >>> over the result. But is there any reason why enhanced-for cannot be >>> made >>> >>> to >>> >>> support Iterators directly? The only thing it does to the provided >>> >>> Iterable >>> >>> is to call iterator() on it, and it does it exactly once; it would >>> just >>> >>> need >>> >>> to use the provided Iterator directly instead. It sounds like it >>> would be >>> >>> trivial to add. >>> >>> >>> >>> >>> >>> The above didn't touch on what the design would look like for eager >>> or >>> >>> lazy/parallel operations. For parallel, the original design can be >>> >>> trivially >>> >>> adapted by moving asParallel() to Iterator directly, and producing >>> some >>> >>> sort >>> >>> of ParallelIterator, which is simply a marker interface to enable >>> >>> parallelization for all applied operations, but otherwise is the same >>> as >>> >>> Iterator (probably just extending it). >>> >>> >>> >>> For eager operations, I would prefer in-place mutating methods >>> returning >>> >>> the >>> >>> receiver (to permit chaining), with distinct but obviously mapped >>> names. >>> >>> For >>> >>> example, if Iterator has withFilter(), then Collection would have >>> >>> filter(). >>> >>> I don't think there is much utility in having eager ops that do a >>> copy, >>> >>> and >>> >>> even less so for chaining such. I think a simple addition of >>> something >>> >>> like >>> >>> clone() to Collection (default implementation could do newInstance() >>> >>> assuming a no-arg constructor available, and then addAll(this) on >>> that >>> >>> new >>> >>> instance) would cover vast majority of all cases where you want to >>> get a >>> >>> copy: the usual pattern would then be to do something like: >>> >>> >>> >>> Collection getWeights() { >>> >>> return things.clone().filter(#Thing.isFoo). >>> >>> transform(#Thing.getWeight); >>> >>> } >>> >>> >>> >>> where both filter() and map() operate in-place on the cloned >>> collection. >>> >>> This also skirts the whole question of the type of the resulting >>> >>> collection >>> >>> produced by a copying operation - it's clear and unambiguous what >>> it'll >>> >>> be >>> >>> for clone(), and no other operation makes a copy. >>> >>> >>> >>> >>> >>> On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz >>> >>> wrote: >>> >>> >>> >>> > Since people are already discussing this based on an experimental >>> >>> > checkin, let me outline the big picture plan here. >>> >>> > >>> >>> > The general idea is to add functional-like operations to >>> collections -- >>> >>> > filter, map, reduce, apply. >>> >>> > >>> >>> > I see three sensible modes, with explicit choices of which you get. >>> >>> > >>> >>> > 1. Serial / Eager. This is the straight >>> >>> > collections-with-functional-style mode, and some samples have >>> already >>> >>> > been checked in as proof of concept. Operations on collections >>> yield >>> >>> > new collections, and you can chain the calls. It values ease of >>> use >>> >>> > over performance (no new concepts like laziness), but the >>> performance >>> >>> > model is still highly predictable. You get things like >>> >>> > >>> >>> > Collection fooAbles = things.filter( #{ t -> t.isFoo() }); >>> >>> > >>> >>> > or, with method references: >>> >>> > >>> >>> > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, >>> pretty >>> >>> > >>> >>> > You can also chain calls together, though you pay a (predictable) >>> >>> > performance cost of intermediate collections, which for small >>> >>> > collections is unlikely to matter: >>> >>> > >>> >>> > maxFooWeight = things.filter(#Thing.isFoo) >>> >>> > .map(#Thing.getWeight) >>> >>> > .max(); >>> >>> > >>> >>> > The benefit here is concision and clarity. The cost is some >>> >>> > performance, but maybe not so much that people freak out. If >>> people >>> >>> > care, they move to the next model, which is: >>> >>> > >>> >>> > 2. Serial / Lazy. Here, the primary abstraction is Stream (name >>> to be >>> >>> > chosen later, Remi used "lazy" in his example.) To transfer >>> between >>> >>> > "eager world" and "lazy world", you use conversion methods >>> (toStream / >>> >>> > toCollection). A typical call chain probably looks like: >>> >>> > collection.toStream / op / op / op / {toCollection,reduce,apply} >>> >>> > >>> >>> > so the above example becomes >>> >>> > >>> >>> > maxFooWeight = things.asStream() >>> >>> > .filter(#Thing.isFoo) >>> >>> > .map(#Thing.getWeight) >>> >>> > .max(); >>> >>> > >>> >>> > The return type of Collection.filter is different from the return >>> type >>> >>> > of Stream.filter, so the choice and performance costs are reflected >>> in >>> >>> > the static type system. This avoids the cost of the intermediate >>> >>> > collections, but is still serial. If you care about that, you move >>> up >>> >>> > to the next model, which is: >>> >>> > >>> >>> > 3. Parallel / Lazy. Here, the primary abstraction is something >>> like >>> >>> > ParallelStream or ParallelIterable. Let's call it ParallelFoo to >>> avoid >>> >>> > bikeshedding for the moment. Now, the code looks like: >>> >>> > >>> >>> > maxFooWeight = things.asParallelFoo() >>> >>> > .filter(#Thing.isFoo) >>> >>> > .map(#Thing.getWeight) >>> >>> > .max(); >>> >>> > >>> >>> > Again, the return type of ParallelFoo.filter is different from >>> >>> > Stream.filter or Collection.filter, so again the choice is >>> reflected in >>> >>> > the static type system. But you don't have to rewrite your code. >>> >>> > >>> >>> > The beauty here is twofold: >>> >>> > >>> >>> > - The base model (serial/eager) is easy to understand and natural >>> to >>> >>> > use as a way of expressing what the programmer wants to do, and >>> >>> > attractive enough to stand on its own -- just a little slow with >>> big >>> >>> > collections. >>> >>> > - Switching between execution models is mostly a matter of adding >>> an >>> >>> > explicit conversion or two in the call chain, as the models are >>> similar >>> >>> > enough that the rest of the code should still work (and even mean >>> the >>> >>> > same thing.) >>> >>> > >>> >>> > >>> >>> > On 3/8/2011 8:43 AM, R?mi Forax wrote: >>> >>> > > Le 08/03/2011 14:31, Jim Mayer a ?crit : >>> >>> > >> // I can tolerate this one >>> >>> > >> long product(List list) { >>> >>> > >> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x >>> -> >>> >>> sum >>> >>> > * x}); >>> >>> > >> } >>> >>> > > >>> >>> > > I prefer this one: >>> >>> > > >>> >>> > > long product(List list) { >>> >>> > > return list.lazy().map(#{x -> (long) x}).reduce(0L, >>> #{sum, >>> >>> x -> >>> >>> > sum * x}); >>> >>> > > } >>> >>> > > >>> >>> > > lazy() means, don't do map directly, but wait and do map and >>> reduce >>> >>> in >>> >>> > > one iteration. >>> >>> > > >>> >>> > > R?mi >>> >>> > > >>> >>> > > >>> >>> > >>> >>> > >>> >>> >>> >>> >>> >> >>> > >>> >>> >> > From grev at miginfocom.com Sun Mar 13 10:25:13 2011 From: grev at miginfocom.com (Mikael Grev) Date: Sun, 13 Mar 2011 18:25:13 +0100 Subject: Design for collections upgrades In-Reply-To: <4D7CFCC2.6060209@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7923E6.1010601@oracle.com> <4D7CFCC2.6060209@oracle.com> Message-ID: <8E858706-0DC6-46B5-8518-03A2616A9E41@miginfocom.com> > >> Finally, I should point out to the language designers out there that >> these APIs can be structured as a monad, not because we want >> programmers to think of them as such but because it provides great >> flexibility in clients wanting to port or reuse code from one >> computational domain to another. Some expert familiar with such >> techniques should take a more firm role influencing the shape of these >> APIs. I don't know who is on the expert group so I can't recommend >> anyone in particular. > > The conclusion in this last sentence doesn't make sense. You can > certainly recommend someone; if by some chance that person happens to be > on the EG already, then your recommendation degenerates into a mere note > of approval. Are you two married? ;) From cgdecker at gmail.com Sun Mar 13 10:28:39 2011 From: cgdecker at gmail.com (Colin Decker) Date: Sun, 13 Mar 2011 13:28:39 -0400 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: I absolutely agree that you shouldn't make an Iterable that can only be used once. Why do you think you can't have a reusable Iterable that represents an infinite series or a large data set though? If you can create an Iterator representing an infinite series, why couldn't you create that Iterator more than once (in which case you can have an Iterable)? -- Colin On Sun, Mar 13, 2011 at 1:24 PM, Jim Mayer wrote: > Yes, you can "do" that with an iterable, but I don't like the idea of an > iterable that can only be used once. Most, if not all, classes that > implement Iterable today have the property that you can call 'iterator' > multiple times to get independent iterators. > > -- Jim > > > On Sun, Mar 13, 2011 at 1:09 PM, Colin Decker wrote: > >> Iterable can represent an infinite series or a very large data set just as >> well as Iterator, given that it is just a factory for Iterators... it isn't >> tied to Collections. Obviously there are some cases where you just want an >> Iterator, and there's no reason that lazy filtering, mapping, etc. can't be >> done on an Iterator as well. >> >> -- >> Colin >> >> >> >> On Sun, Mar 13, 2011 at 12:38 PM, Jim Mayer wrote: >> >>> I have a different take on this. Non-reusable streams (e.g., Iterator, >>> not Iterable) can be used to represent data structures that cannot be easily >>> regenerated. Infinite series come to mind, as well as data sets that are >>> very large or come from non-determinate sources. Since lazily evaluated >>> streams can represent these gracefully and collections cannot (what do you >>> return for the size of a infinte series?), why cripple the stream >>> abstraction by tying it to collections? On the other hand, if a stream is >>> backed by a collection, one can simply call "asStream()" again to get a >>> "rewound" series. >>> >>> So, instead of using Iterable, I'd prefer something like this: >>> >>> (1) Collections sport an "asStream" (or even the existing "iterator()" >>> method, if Iterator turns out to be flexible enough). >>> (2) That whatever class/interface is the result of "asStream" support an >>> API for creating instances outside of the Collections framework (note that >>> Iterator already does this). >>> (3) That we consider making one of the operators something that can >>> "truncate" an infinite series. >>> >>> With this kind of framework one could have the same kind of thing we've >>> been talking about: >>> >>> int sum(Collection s) { >>> return s.asStream().fold(#{sum, x -> sum + x}, 0); >>> } >>> >>> but could also have: >>> >>> int sum(BufferedReader r) { >>> return r.asStream(r#readLine).map(Integer#valueOf).fold(#{sum, >>> x-> sum + x}, 0); >>> } >>> >>> or even: >>> >>> int sum(StreamTypeThing s, int count) { >>> return s.prefix(count).fold(#{sum, x -> sum + x}, 0); >>> } >>> >>> As a side note, I agree with one of the earlier posters that if we did >>> something like this we'd want to allow stuff like: >>> >>> for (String x : c.asStream().map(...)) {} >>> >>> -- Jim >>> >>> On Sat, Mar 12, 2011 at 11:37 PM, Colin Decker wrote: >>> >>>> Because there's no need to and because Iterables (being reusable) are >>>> far >>>> more flexible than Iterators. The Iterable interface is just as lazy as >>>> Iterator. The Stream interface should be Iterable. >>>> >>>> -- >>>> Colin >>>> >>>> >>>> On Sat, Mar 12, 2011 at 11:08 PM, Pavel Minaev >>>> wrote: >>>> >>>> > I'm curious as to why you think that limiting lazy operations to >>>> iterators >>>> > (or streams - the name is immaterial) is undesirable? In terms of >>>> code, it >>>> > is exactly the same as the proposal which started the thread, with a >>>> need >>>> > for one extra method call - iterator() rather than asStream() - on >>>> the >>>> > collection, before you are in the lazy land. In terms of semantics, it >>>> > avoids introduction of new abstractions where existing ones are >>>> sufficient >>>> > to capture the intent (iterators are inherently lazy). >>>> > >>>> > On Sat, Mar 12, 2011 at 7:53 PM, Colin Decker >>>> wrote: >>>> > >>>> >> I don't feel like a comparison to InputStream etc. makes much sense >>>> >> considering "Stream" is an arbitrary name that can easily be changed >>>> to >>>> >> something more appropriate ("Streamable", say). I also think it's a >>>> weakness >>>> >> of the IO streams that they don't have an Iterable equivalent (like >>>> >> InputSupplier from Guava). Regardless, limiting lazy filter/map to >>>> Iterator >>>> >> would be... undesirable. I do think Iterator should have such methods >>>> as >>>> >> well, though. >>>> >> >>>> >> -- >>>> >> Colin >>>> >> >>>> >> >>>> >> >>>> >> On Sat, Mar 12, 2011 at 8:30 PM, Pavel Minaev >>>> wrote: >>>> >> >>>> >>> I've been re-reading the "Design for collection upgrades" thread, >>>> and had >>>> >>> some thoughts on the nature of the Stream abstraction (for >>>> lazy/serial >>>> >>> scenario) as originally outlined in Brian's post that kicked off the >>>> >>> thread, >>>> >>> and users expectations of what comes with that name. >>>> >>> >>>> >>> Per the proposal, it sounds like Stream is more or less a marker >>>> >>> interface >>>> >>> to indicate lazy operations, and not otherwise any different from >>>> >>> Iterable. >>>> >>> However, this isn't what "stream" has historically meant in >>>> imperative >>>> >>> PLs >>>> >>> and their frameworks. For some examples of what I mean, let me point >>>> at >>>> >>> java.io.InputStream, or at C++ std::basic_istream. In both cases, >>>> the >>>> >>> fundamental property of the streams - the one that is guaranteed to >>>> be >>>> >>> supported by _any_ stream - is that you can read elements. >>>> InputStream >>>> >>> also >>>> >>> offers mark()/reset(), but those are conditionally supported, and so >>>> are >>>> >>> not >>>> >>> part of the basic contract of the abstraction; they could (one could >>>> even >>>> >>> argue that, from a pure OOD approach, they should) just as well be >>>> moved >>>> >>> to >>>> >>> a more concrete interface that could be queried by clients instead >>>> of >>>> >>> using >>>> >>> markSupported(). >>>> >>> >>>> >>> The important thing with that basic contract is that once a value is >>>> read >>>> >>> from a stream, it stays read: a stream by itself is a read-once >>>> sequence. >>>> >>> There may be ways to obtain another stream that would re-read the >>>> same >>>> >>> exact >>>> >>> elements, but that would still be a new stream object. For streams >>>> that >>>> >>> wrap >>>> >>> some data store (e.g. FileInputStream or ByteArrayInputStream), the >>>> >>> stream >>>> >>> object is essentially a cursor into the store - it has a current >>>> >>> position, >>>> >>> which every read advances towards the end of the store. Furthermore, >>>> the >>>> >>> stream is not _the_ store - you can have several FileInputStreams >>>> over >>>> >>> the >>>> >>> same file, or several ByteArrayInputStreams sharing the same byte >>>> array. >>>> >>> >>>> >>> Now if we take the above and see how it applies to collections, it >>>> >>> actually >>>> >>> is a very familiar concept: something that is not a collection >>>> itself, >>>> >>> but >>>> >>> is a forward-only cursor for a collection, and each collection may >>>> have >>>> >>> more >>>> >>> than one such cursor - why, that is Iterator. Its next() and >>>> hasNext() >>>> >>> methods match exactly the basic input stream contract; remove() does >>>> not, >>>> >>> but it is conditionally-supported anyway. An analogy to highlight >>>> this >>>> >>> point: Iterator is to Iterable/Collection what ByteArrayInputStream >>>> is to >>>> >>> byte array. >>>> >>> >>>> >>> Iterators, being cursors, are also naturally expected to be lazy by >>>> API >>>> >>> clients - if I provide a method that takes an iterator, applies a >>>> filter >>>> >>> to >>>> >>> it, and returns another iterator as a result, no-one would expect >>>> >>> filtering >>>> >>> to occur over the entire collection right there and then. It's clear >>>> that >>>> >>> the result of such operation is a "filtered iterator", that would >>>> apply >>>> >>> the >>>> >>> filter as it is being iterated. >>>> >>> >>>> >>> So, then, why not put lazy map/filter/reduce/... on Iterator? Thus, >>>> >>> Brian's >>>> >>> original serial/lazy example would become: >>>> >>> >>>> >>> maxFooWeight = things.iterator() >>>> >>> .filter(#Thing.isFoo) >>>> >>> .map(#Thing.getWeight) >>>> >>> .max(); >>>> >>> >>>> >>> or maybe with some less concise but more descriptive (and - purely >>>> >>> subjectively - "Java-like") names: >>>> >>> >>>> >>> maxFooWeight = things.iterator() >>>> >>> .withFilter(#Thing.isFoo) >>>> >>> .withTransform(#Thing.getWeight) >>>> >>> .getLargestValue(); >>>> >>> >>>> >>> This has a nice property of working with a more fundamental >>>> abstraction >>>> >>> than >>>> >>> collections - I can write an Iterator that wraps a non-rewindable >>>> I/O >>>> >>> InputStream, but I cannot write such an Iterable (well, I can - if >>>> it >>>> >>> throws >>>> >>> after the first call to iterator() - but it will only be usable with >>>> APIs >>>> >>> which specify that they only call iterator() on the provided >>>> Iterable >>>> >>> once >>>> >>> as part of their public contract; otherwise, I'm relying on an >>>> >>> implementation detail). >>>> >>> >>>> >>> The only major annoyance I can see with this approach is that >>>> >>> enhanced-for-loop only supports Iterables (and arrays) but not >>>> Iterators, >>>> >>> and so you'd have to write a manual loop with next()/hasNext() to >>>> iterate >>>> >>> over the result. But is there any reason why enhanced-for cannot be >>>> made >>>> >>> to >>>> >>> support Iterators directly? The only thing it does to the provided >>>> >>> Iterable >>>> >>> is to call iterator() on it, and it does it exactly once; it would >>>> just >>>> >>> need >>>> >>> to use the provided Iterator directly instead. It sounds like it >>>> would be >>>> >>> trivial to add. >>>> >>> >>>> >>> >>>> >>> The above didn't touch on what the design would look like for eager >>>> or >>>> >>> lazy/parallel operations. For parallel, the original design can be >>>> >>> trivially >>>> >>> adapted by moving asParallel() to Iterator directly, and producing >>>> some >>>> >>> sort >>>> >>> of ParallelIterator, which is simply a marker interface to enable >>>> >>> parallelization for all applied operations, but otherwise is the >>>> same as >>>> >>> Iterator (probably just extending it). >>>> >>> >>>> >>> For eager operations, I would prefer in-place mutating methods >>>> returning >>>> >>> the >>>> >>> receiver (to permit chaining), with distinct but obviously mapped >>>> names. >>>> >>> For >>>> >>> example, if Iterator has withFilter(), then Collection would have >>>> >>> filter(). >>>> >>> I don't think there is much utility in having eager ops that do a >>>> copy, >>>> >>> and >>>> >>> even less so for chaining such. I think a simple addition of >>>> something >>>> >>> like >>>> >>> clone() to Collection (default implementation could do newInstance() >>>> >>> assuming a no-arg constructor available, and then addAll(this) on >>>> that >>>> >>> new >>>> >>> instance) would cover vast majority of all cases where you want to >>>> get a >>>> >>> copy: the usual pattern would then be to do something like: >>>> >>> >>>> >>> Collection getWeights() { >>>> >>> return things.clone().filter(#Thing.isFoo). >>>> >>> transform(#Thing.getWeight); >>>> >>> } >>>> >>> >>>> >>> where both filter() and map() operate in-place on the cloned >>>> collection. >>>> >>> This also skirts the whole question of the type of the resulting >>>> >>> collection >>>> >>> produced by a copying operation - it's clear and unambiguous what >>>> it'll >>>> >>> be >>>> >>> for clone(), and no other operation makes a copy. >>>> >>> >>>> >>> >>>> >>> On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz >>> > >>>> >>> wrote: >>>> >>> >>>> >>> > Since people are already discussing this based on an experimental >>>> >>> > checkin, let me outline the big picture plan here. >>>> >>> > >>>> >>> > The general idea is to add functional-like operations to >>>> collections -- >>>> >>> > filter, map, reduce, apply. >>>> >>> > >>>> >>> > I see three sensible modes, with explicit choices of which you >>>> get. >>>> >>> > >>>> >>> > 1. Serial / Eager. This is the straight >>>> >>> > collections-with-functional-style mode, and some samples have >>>> already >>>> >>> > been checked in as proof of concept. Operations on collections >>>> yield >>>> >>> > new collections, and you can chain the calls. It values ease of >>>> use >>>> >>> > over performance (no new concepts like laziness), but the >>>> performance >>>> >>> > model is still highly predictable. You get things like >>>> >>> > >>>> >>> > Collection fooAbles = things.filter( #{ t -> t.isFoo() }); >>>> >>> > >>>> >>> > or, with method references: >>>> >>> > >>>> >>> > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, >>>> pretty >>>> >>> > >>>> >>> > You can also chain calls together, though you pay a (predictable) >>>> >>> > performance cost of intermediate collections, which for small >>>> >>> > collections is unlikely to matter: >>>> >>> > >>>> >>> > maxFooWeight = things.filter(#Thing.isFoo) >>>> >>> > .map(#Thing.getWeight) >>>> >>> > .max(); >>>> >>> > >>>> >>> > The benefit here is concision and clarity. The cost is some >>>> >>> > performance, but maybe not so much that people freak out. If >>>> people >>>> >>> > care, they move to the next model, which is: >>>> >>> > >>>> >>> > 2. Serial / Lazy. Here, the primary abstraction is Stream (name >>>> to be >>>> >>> > chosen later, Remi used "lazy" in his example.) To transfer >>>> between >>>> >>> > "eager world" and "lazy world", you use conversion methods >>>> (toStream / >>>> >>> > toCollection). A typical call chain probably looks like: >>>> >>> > collection.toStream / op / op / op / {toCollection,reduce,apply} >>>> >>> > >>>> >>> > so the above example becomes >>>> >>> > >>>> >>> > maxFooWeight = things.asStream() >>>> >>> > .filter(#Thing.isFoo) >>>> >>> > .map(#Thing.getWeight) >>>> >>> > .max(); >>>> >>> > >>>> >>> > The return type of Collection.filter is different from the return >>>> type >>>> >>> > of Stream.filter, so the choice and performance costs are >>>> reflected in >>>> >>> > the static type system. This avoids the cost of the intermediate >>>> >>> > collections, but is still serial. If you care about that, you >>>> move up >>>> >>> > to the next model, which is: >>>> >>> > >>>> >>> > 3. Parallel / Lazy. Here, the primary abstraction is something >>>> like >>>> >>> > ParallelStream or ParallelIterable. Let's call it ParallelFoo to >>>> avoid >>>> >>> > bikeshedding for the moment. Now, the code looks like: >>>> >>> > >>>> >>> > maxFooWeight = things.asParallelFoo() >>>> >>> > .filter(#Thing.isFoo) >>>> >>> > .map(#Thing.getWeight) >>>> >>> > .max(); >>>> >>> > >>>> >>> > Again, the return type of ParallelFoo.filter is different from >>>> >>> > Stream.filter or Collection.filter, so again the choice is >>>> reflected in >>>> >>> > the static type system. But you don't have to rewrite your code. >>>> >>> > >>>> >>> > The beauty here is twofold: >>>> >>> > >>>> >>> > - The base model (serial/eager) is easy to understand and natural >>>> to >>>> >>> > use as a way of expressing what the programmer wants to do, and >>>> >>> > attractive enough to stand on its own -- just a little slow with >>>> big >>>> >>> > collections. >>>> >>> > - Switching between execution models is mostly a matter of adding >>>> an >>>> >>> > explicit conversion or two in the call chain, as the models are >>>> similar >>>> >>> > enough that the rest of the code should still work (and even mean >>>> the >>>> >>> > same thing.) >>>> >>> > >>>> >>> > >>>> >>> > On 3/8/2011 8:43 AM, R?mi Forax wrote: >>>> >>> > > Le 08/03/2011 14:31, Jim Mayer a ?crit : >>>> >>> > >> // I can tolerate this one >>>> >>> > >> long product(List list) { >>>> >>> > >> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x >>>> -> >>>> >>> sum >>>> >>> > * x}); >>>> >>> > >> } >>>> >>> > > >>>> >>> > > I prefer this one: >>>> >>> > > >>>> >>> > > long product(List list) { >>>> >>> > > return list.lazy().map(#{x -> (long) x}).reduce(0L, >>>> #{sum, >>>> >>> x -> >>>> >>> > sum * x}); >>>> >>> > > } >>>> >>> > > >>>> >>> > > lazy() means, don't do map directly, but wait and do map and >>>> reduce >>>> >>> in >>>> >>> > > one iteration. >>>> >>> > > >>>> >>> > > R?mi >>>> >>> > > >>>> >>> > > >>>> >>> > >>>> >>> > >>>> >>> >>>> >>> >>>> >> >>>> > >>>> >>>> >>> >> > From neal at gafter.com Sun Mar 13 10:41:15 2011 From: neal at gafter.com (Neal Gafter) Date: Sun, 13 Mar 2011 10:41:15 -0700 Subject: Design for collections upgrades In-Reply-To: <4D7CFCC2.6060209@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7923E6.1010601@oracle.com> <4D7CFCC2.6060209@oracle.com> Message-ID: On Sun, Mar 13, 2011 at 10:20 AM, Brian Goetz wrote: > > Finally, I should point out to the language designers out there that > > these APIs can be structured as a monad, not because we want > > programmers to think of them as such but because it provides great > > flexibility in clients wanting to port or reuse code from one > > computational domain to another. Some expert familiar with such > > techniques should take a more firm role influencing the shape of these > > APIs. I don't know who is on the expert group so I can't recommend > > anyone in particular. > > The conclusion in this last sentence doesn't make sense. You can > certainly recommend someone; if by some chance that person happens to be > on the EG already, then your recommendation degenerates into a mere note > of approval. > Um, OK. I recommend Erik Meijer. Cheers, Neal From jim at pentastich.org Sun Mar 13 10:42:49 2011 From: jim at pentastich.org (Jim Mayer) Date: Sun, 13 Mar 2011 13:42:49 -0400 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: You can for things like the Fibonacci series that can be generated from scratch. You can't for things like data being read off of a stream or data being read from a sensor. In the case of the Fibonacci series, by all means let them implement Iteratable. It's a cool data structure. -- Jim On Sun, Mar 13, 2011 at 1:28 PM, Colin Decker wrote: > I absolutely agree that you shouldn't make an Iterable that can only be > used once. Why do you think you can't have a reusable Iterable that > represents an infinite series or a large data set though? If you can create > an Iterator representing an infinite series, why couldn't you create that > Iterator more than once (in which case you can have an Iterable)? > > -- > Colin > > > > On Sun, Mar 13, 2011 at 1:24 PM, Jim Mayer wrote: > >> Yes, you can "do" that with an iterable, but I don't like the idea of an >> iterable that can only be used once. Most, if not all, classes that >> implement Iterable today have the property that you can call 'iterator' >> multiple times to get independent iterators. >> >> -- Jim >> >> >> On Sun, Mar 13, 2011 at 1:09 PM, Colin Decker wrote: >> >>> Iterable can represent an infinite series or a very large data set just >>> as well as Iterator, given that it is just a factory for Iterators... it >>> isn't tied to Collections. Obviously there are some cases where you just >>> want an Iterator, and there's no reason that lazy filtering, mapping, etc. >>> can't be done on an Iterator as well. >>> >>> -- >>> Colin >>> >>> >>> >>> On Sun, Mar 13, 2011 at 12:38 PM, Jim Mayer wrote: >>> >>>> I have a different take on this. Non-reusable streams (e.g., Iterator, >>>> not Iterable) can be used to represent data structures that cannot be easily >>>> regenerated. Infinite series come to mind, as well as data sets that are >>>> very large or come from non-determinate sources. Since lazily evaluated >>>> streams can represent these gracefully and collections cannot (what do you >>>> return for the size of a infinte series?), why cripple the stream >>>> abstraction by tying it to collections? On the other hand, if a stream is >>>> backed by a collection, one can simply call "asStream()" again to get a >>>> "rewound" series. >>>> >>>> So, instead of using Iterable, I'd prefer something like this: >>>> >>>> (1) Collections sport an "asStream" (or even the existing "iterator()" >>>> method, if Iterator turns out to be flexible enough). >>>> (2) That whatever class/interface is the result of "asStream" support an >>>> API for creating instances outside of the Collections framework (note that >>>> Iterator already does this). >>>> (3) That we consider making one of the operators something that can >>>> "truncate" an infinite series. >>>> >>>> With this kind of framework one could have the same kind of thing we've >>>> been talking about: >>>> >>>> int sum(Collection s) { >>>> return s.asStream().fold(#{sum, x -> sum + x}, 0); >>>> } >>>> >>>> but could also have: >>>> >>>> int sum(BufferedReader r) { >>>> return r.asStream(r#readLine).map(Integer#valueOf).fold(#{sum, >>>> x-> sum + x}, 0); >>>> } >>>> >>>> or even: >>>> >>>> int sum(StreamTypeThing s, int count) { >>>> return s.prefix(count).fold(#{sum, x -> sum + x}, 0); >>>> } >>>> >>>> As a side note, I agree with one of the earlier posters that if we did >>>> something like this we'd want to allow stuff like: >>>> >>>> for (String x : c.asStream().map(...)) {} >>>> >>>> -- Jim >>>> >>>> On Sat, Mar 12, 2011 at 11:37 PM, Colin Decker wrote: >>>> >>>>> Because there's no need to and because Iterables (being reusable) are >>>>> far >>>>> more flexible than Iterators. The Iterable interface is just as lazy as >>>>> Iterator. The Stream interface should be Iterable. >>>>> >>>>> -- >>>>> Colin >>>>> >>>>> >>>>> On Sat, Mar 12, 2011 at 11:08 PM, Pavel Minaev >>>>> wrote: >>>>> >>>>> > I'm curious as to why you think that limiting lazy operations to >>>>> iterators >>>>> > (or streams - the name is immaterial) is undesirable? In terms of >>>>> code, it >>>>> > is exactly the same as the proposal which started the thread, with a >>>>> need >>>>> > for one extra method call - iterator() rather than asStream() - on >>>>> the >>>>> > collection, before you are in the lazy land. In terms of semantics, >>>>> it >>>>> > avoids introduction of new abstractions where existing ones are >>>>> sufficient >>>>> > to capture the intent (iterators are inherently lazy). >>>>> > >>>>> > On Sat, Mar 12, 2011 at 7:53 PM, Colin Decker >>>>> wrote: >>>>> > >>>>> >> I don't feel like a comparison to InputStream etc. makes much sense >>>>> >> considering "Stream" is an arbitrary name that can easily be changed >>>>> to >>>>> >> something more appropriate ("Streamable", say). I also think it's a >>>>> weakness >>>>> >> of the IO streams that they don't have an Iterable equivalent (like >>>>> >> InputSupplier from Guava). Regardless, limiting lazy filter/map to >>>>> Iterator >>>>> >> would be... undesirable. I do think Iterator should have such >>>>> methods as >>>>> >> well, though. >>>>> >> >>>>> >> -- >>>>> >> Colin >>>>> >> >>>>> >> >>>>> >> >>>>> >> On Sat, Mar 12, 2011 at 8:30 PM, Pavel Minaev >>>>> wrote: >>>>> >> >>>>> >>> I've been re-reading the "Design for collection upgrades" thread, >>>>> and had >>>>> >>> some thoughts on the nature of the Stream abstraction (for >>>>> lazy/serial >>>>> >>> scenario) as originally outlined in Brian's post that kicked off >>>>> the >>>>> >>> thread, >>>>> >>> and users expectations of what comes with that name. >>>>> >>> >>>>> >>> Per the proposal, it sounds like Stream is more or less a marker >>>>> >>> interface >>>>> >>> to indicate lazy operations, and not otherwise any different from >>>>> >>> Iterable. >>>>> >>> However, this isn't what "stream" has historically meant in >>>>> imperative >>>>> >>> PLs >>>>> >>> and their frameworks. For some examples of what I mean, let me >>>>> point at >>>>> >>> java.io.InputStream, or at C++ std::basic_istream. In both cases, >>>>> the >>>>> >>> fundamental property of the streams - the one that is guaranteed to >>>>> be >>>>> >>> supported by _any_ stream - is that you can read elements. >>>>> InputStream >>>>> >>> also >>>>> >>> offers mark()/reset(), but those are conditionally supported, and >>>>> so are >>>>> >>> not >>>>> >>> part of the basic contract of the abstraction; they could (one >>>>> could even >>>>> >>> argue that, from a pure OOD approach, they should) just as well be >>>>> moved >>>>> >>> to >>>>> >>> a more concrete interface that could be queried by clients instead >>>>> of >>>>> >>> using >>>>> >>> markSupported(). >>>>> >>> >>>>> >>> The important thing with that basic contract is that once a value >>>>> is read >>>>> >>> from a stream, it stays read: a stream by itself is a read-once >>>>> sequence. >>>>> >>> There may be ways to obtain another stream that would re-read the >>>>> same >>>>> >>> exact >>>>> >>> elements, but that would still be a new stream object. For streams >>>>> that >>>>> >>> wrap >>>>> >>> some data store (e.g. FileInputStream or ByteArrayInputStream), the >>>>> >>> stream >>>>> >>> object is essentially a cursor into the store - it has a current >>>>> >>> position, >>>>> >>> which every read advances towards the end of the store. >>>>> Furthermore, the >>>>> >>> stream is not _the_ store - you can have several FileInputStreams >>>>> over >>>>> >>> the >>>>> >>> same file, or several ByteArrayInputStreams sharing the same byte >>>>> array. >>>>> >>> >>>>> >>> Now if we take the above and see how it applies to collections, it >>>>> >>> actually >>>>> >>> is a very familiar concept: something that is not a collection >>>>> itself, >>>>> >>> but >>>>> >>> is a forward-only cursor for a collection, and each collection may >>>>> have >>>>> >>> more >>>>> >>> than one such cursor - why, that is Iterator. Its next() and >>>>> hasNext() >>>>> >>> methods match exactly the basic input stream contract; remove() >>>>> does not, >>>>> >>> but it is conditionally-supported anyway. An analogy to highlight >>>>> this >>>>> >>> point: Iterator is to Iterable/Collection what ByteArrayInputStream >>>>> is to >>>>> >>> byte array. >>>>> >>> >>>>> >>> Iterators, being cursors, are also naturally expected to be lazy by >>>>> API >>>>> >>> clients - if I provide a method that takes an iterator, applies a >>>>> filter >>>>> >>> to >>>>> >>> it, and returns another iterator as a result, no-one would expect >>>>> >>> filtering >>>>> >>> to occur over the entire collection right there and then. It's >>>>> clear that >>>>> >>> the result of such operation is a "filtered iterator", that would >>>>> apply >>>>> >>> the >>>>> >>> filter as it is being iterated. >>>>> >>> >>>>> >>> So, then, why not put lazy map/filter/reduce/... on Iterator? Thus, >>>>> >>> Brian's >>>>> >>> original serial/lazy example would become: >>>>> >>> >>>>> >>> maxFooWeight = things.iterator() >>>>> >>> .filter(#Thing.isFoo) >>>>> >>> .map(#Thing.getWeight) >>>>> >>> .max(); >>>>> >>> >>>>> >>> or maybe with some less concise but more descriptive (and - purely >>>>> >>> subjectively - "Java-like") names: >>>>> >>> >>>>> >>> maxFooWeight = things.iterator() >>>>> >>> .withFilter(#Thing.isFoo) >>>>> >>> .withTransform(#Thing.getWeight) >>>>> >>> .getLargestValue(); >>>>> >>> >>>>> >>> This has a nice property of working with a more fundamental >>>>> abstraction >>>>> >>> than >>>>> >>> collections - I can write an Iterator that wraps a non-rewindable >>>>> I/O >>>>> >>> InputStream, but I cannot write such an Iterable (well, I can - if >>>>> it >>>>> >>> throws >>>>> >>> after the first call to iterator() - but it will only be usable >>>>> with APIs >>>>> >>> which specify that they only call iterator() on the provided >>>>> Iterable >>>>> >>> once >>>>> >>> as part of their public contract; otherwise, I'm relying on an >>>>> >>> implementation detail). >>>>> >>> >>>>> >>> The only major annoyance I can see with this approach is that >>>>> >>> enhanced-for-loop only supports Iterables (and arrays) but not >>>>> Iterators, >>>>> >>> and so you'd have to write a manual loop with next()/hasNext() to >>>>> iterate >>>>> >>> over the result. But is there any reason why enhanced-for cannot be >>>>> made >>>>> >>> to >>>>> >>> support Iterators directly? The only thing it does to the provided >>>>> >>> Iterable >>>>> >>> is to call iterator() on it, and it does it exactly once; it would >>>>> just >>>>> >>> need >>>>> >>> to use the provided Iterator directly instead. It sounds like it >>>>> would be >>>>> >>> trivial to add. >>>>> >>> >>>>> >>> >>>>> >>> The above didn't touch on what the design would look like for eager >>>>> or >>>>> >>> lazy/parallel operations. For parallel, the original design can be >>>>> >>> trivially >>>>> >>> adapted by moving asParallel() to Iterator directly, and producing >>>>> some >>>>> >>> sort >>>>> >>> of ParallelIterator, which is simply a marker interface to enable >>>>> >>> parallelization for all applied operations, but otherwise is the >>>>> same as >>>>> >>> Iterator (probably just extending it). >>>>> >>> >>>>> >>> For eager operations, I would prefer in-place mutating methods >>>>> returning >>>>> >>> the >>>>> >>> receiver (to permit chaining), with distinct but obviously mapped >>>>> names. >>>>> >>> For >>>>> >>> example, if Iterator has withFilter(), then Collection would have >>>>> >>> filter(). >>>>> >>> I don't think there is much utility in having eager ops that do a >>>>> copy, >>>>> >>> and >>>>> >>> even less so for chaining such. I think a simple addition of >>>>> something >>>>> >>> like >>>>> >>> clone() to Collection (default implementation could do >>>>> newInstance() >>>>> >>> assuming a no-arg constructor available, and then addAll(this) on >>>>> that >>>>> >>> new >>>>> >>> instance) would cover vast majority of all cases where you want to >>>>> get a >>>>> >>> copy: the usual pattern would then be to do something like: >>>>> >>> >>>>> >>> Collection getWeights() { >>>>> >>> return things.clone().filter(#Thing.isFoo). >>>>> >>> transform(#Thing.getWeight); >>>>> >>> } >>>>> >>> >>>>> >>> where both filter() and map() operate in-place on the cloned >>>>> collection. >>>>> >>> This also skirts the whole question of the type of the resulting >>>>> >>> collection >>>>> >>> produced by a copying operation - it's clear and unambiguous what >>>>> it'll >>>>> >>> be >>>>> >>> for clone(), and no other operation makes a copy. >>>>> >>> >>>>> >>> >>>>> >>> On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz < >>>>> brian.goetz at oracle.com> >>>>> >>> wrote: >>>>> >>> >>>>> >>> > Since people are already discussing this based on an experimental >>>>> >>> > checkin, let me outline the big picture plan here. >>>>> >>> > >>>>> >>> > The general idea is to add functional-like operations to >>>>> collections -- >>>>> >>> > filter, map, reduce, apply. >>>>> >>> > >>>>> >>> > I see three sensible modes, with explicit choices of which you >>>>> get. >>>>> >>> > >>>>> >>> > 1. Serial / Eager. This is the straight >>>>> >>> > collections-with-functional-style mode, and some samples have >>>>> already >>>>> >>> > been checked in as proof of concept. Operations on collections >>>>> yield >>>>> >>> > new collections, and you can chain the calls. It values ease of >>>>> use >>>>> >>> > over performance (no new concepts like laziness), but the >>>>> performance >>>>> >>> > model is still highly predictable. You get things like >>>>> >>> > >>>>> >>> > Collection fooAbles = things.filter( #{ t -> t.isFoo() }); >>>>> >>> > >>>>> >>> > or, with method references: >>>>> >>> > >>>>> >>> > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, >>>>> pretty >>>>> >>> > >>>>> >>> > You can also chain calls together, though you pay a (predictable) >>>>> >>> > performance cost of intermediate collections, which for small >>>>> >>> > collections is unlikely to matter: >>>>> >>> > >>>>> >>> > maxFooWeight = things.filter(#Thing.isFoo) >>>>> >>> > .map(#Thing.getWeight) >>>>> >>> > .max(); >>>>> >>> > >>>>> >>> > The benefit here is concision and clarity. The cost is some >>>>> >>> > performance, but maybe not so much that people freak out. If >>>>> people >>>>> >>> > care, they move to the next model, which is: >>>>> >>> > >>>>> >>> > 2. Serial / Lazy. Here, the primary abstraction is Stream (name >>>>> to be >>>>> >>> > chosen later, Remi used "lazy" in his example.) To transfer >>>>> between >>>>> >>> > "eager world" and "lazy world", you use conversion methods >>>>> (toStream / >>>>> >>> > toCollection). A typical call chain probably looks like: >>>>> >>> > collection.toStream / op / op / op / >>>>> {toCollection,reduce,apply} >>>>> >>> > >>>>> >>> > so the above example becomes >>>>> >>> > >>>>> >>> > maxFooWeight = things.asStream() >>>>> >>> > .filter(#Thing.isFoo) >>>>> >>> > .map(#Thing.getWeight) >>>>> >>> > .max(); >>>>> >>> > >>>>> >>> > The return type of Collection.filter is different from the return >>>>> type >>>>> >>> > of Stream.filter, so the choice and performance costs are >>>>> reflected in >>>>> >>> > the static type system. This avoids the cost of the intermediate >>>>> >>> > collections, but is still serial. If you care about that, you >>>>> move up >>>>> >>> > to the next model, which is: >>>>> >>> > >>>>> >>> > 3. Parallel / Lazy. Here, the primary abstraction is something >>>>> like >>>>> >>> > ParallelStream or ParallelIterable. Let's call it ParallelFoo to >>>>> avoid >>>>> >>> > bikeshedding for the moment. Now, the code looks like: >>>>> >>> > >>>>> >>> > maxFooWeight = things.asParallelFoo() >>>>> >>> > .filter(#Thing.isFoo) >>>>> >>> > .map(#Thing.getWeight) >>>>> >>> > .max(); >>>>> >>> > >>>>> >>> > Again, the return type of ParallelFoo.filter is different from >>>>> >>> > Stream.filter or Collection.filter, so again the choice is >>>>> reflected in >>>>> >>> > the static type system. But you don't have to rewrite your code. >>>>> >>> > >>>>> >>> > The beauty here is twofold: >>>>> >>> > >>>>> >>> > - The base model (serial/eager) is easy to understand and >>>>> natural to >>>>> >>> > use as a way of expressing what the programmer wants to do, and >>>>> >>> > attractive enough to stand on its own -- just a little slow with >>>>> big >>>>> >>> > collections. >>>>> >>> > - Switching between execution models is mostly a matter of >>>>> adding an >>>>> >>> > explicit conversion or two in the call chain, as the models are >>>>> similar >>>>> >>> > enough that the rest of the code should still work (and even mean >>>>> the >>>>> >>> > same thing.) >>>>> >>> > >>>>> >>> > >>>>> >>> > On 3/8/2011 8:43 AM, R?mi Forax wrote: >>>>> >>> > > Le 08/03/2011 14:31, Jim Mayer a ?crit : >>>>> >>> > >> // I can tolerate this one >>>>> >>> > >> long product(List list) { >>>>> >>> > >> return list.map(#{x -> (long) x}).reduce(0L, #{sum, >>>>> x -> >>>>> >>> sum >>>>> >>> > * x}); >>>>> >>> > >> } >>>>> >>> > > >>>>> >>> > > I prefer this one: >>>>> >>> > > >>>>> >>> > > long product(List list) { >>>>> >>> > > return list.lazy().map(#{x -> (long) x}).reduce(0L, >>>>> #{sum, >>>>> >>> x -> >>>>> >>> > sum * x}); >>>>> >>> > > } >>>>> >>> > > >>>>> >>> > > lazy() means, don't do map directly, but wait and do map and >>>>> reduce >>>>> >>> in >>>>> >>> > > one iteration. >>>>> >>> > > >>>>> >>> > > R?mi >>>>> >>> > > >>>>> >>> > > >>>>> >>> > >>>>> >>> > >>>>> >>> >>>>> >>> >>>>> >> >>>>> > >>>>> >>>>> >>>> >>> >> > From sam at sampullara.com Sun Mar 13 12:01:44 2011 From: sam at sampullara.com (Sam Pullara) Date: Sun, 13 Mar 2011 12:01:44 -0700 Subject: Design for collections upgrades In-Reply-To: <4D7CA697.7080300@comp.lancs.ac.uk> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7CA697.7080300@comp.lancs.ac.uk> Message-ID: For the last year or so I have been using the Google Collections library, now distributed as part of Guava. It has most of the APIs that we are talking about and I think that regular Java programmers are using them. They separate out Lists, Iterables, Sets, Maps, Collections and Iterators. Most of the code that I have written would work great with the methods in these classes added as extension methods to the normal APIs. Function literals would of course slot right in. Here are some links to their APIs: http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Iterables.html http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Iterators.html http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Lists.html http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Sets.html http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Maps.html http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Collections2.html My understanding is that they have an advantage over extension methods in the caller determines how to treat the target collection. For example, if you use: public class Iterables { public static Iterable transform(Iterable fromIterable, Function function)... } You get streaming behavior whereas the equivalent in Lists is evaluated eagerly: public class Lists { public static List transform(List fromList, Function function) } Apparently with extension methods we don't have this luxury as the type at the call site does not pick the extension method default but instead the underlying implementation does. Because of this it appears that the current proposals for things like .asStream() will actually end up being more verbose than using their Guava counterparts once function literals are available. As for the naming conventions, Guava went with filter/transform. Personally, I renamed them f/t since chaining together several in Guava gets a little silly with such long names since they show up next to one another. Here is some current code of mine: return l(t(f(s.bagService.featured(0, 30L, category), new P>() { public boolean apply(@Nullable Row input) { return input != null && ids.add(input.value.owner()); } }), new F, BagCodeFactory.BagCode>() { public BagCodeFactory.BagCode apply(Row input) { return new BagCodeFactory(s).getBag(page, input); } }), count); l = limit, t = transform, f = filter In JDK8 with function literals it would look like (featured() returns an Iterable): return l(t(f(s.bagService.featured(0, 30L, category), #{ input -> input != null && ids.add(input.value.owner())}), #{ input -> new BagCodeFactory(s).getBag(page, input)}), count); Now, using some of the suggestions on the list so far, it could look like: return s.bagService.featured(0, 30L, category).asStream().fiter(#{ input -> input != null && ids.add(input.value.owner())}) .transform(#{ input -> new BagCodeFactory(s).getBag(page, input)}).limit(count); Which isn't too bad though since featured() is already returning an Iterable it feels redundant to asStream() it especially since it really is an Iterable only and doesn't use an underlying Java collection at all. It concerns me that the call site can't control behavior through typing. If we only put the extension methods on Iterable/Iterator it would be pretty easy for the developer to see that the operations are lazy and there would never be any confusion as to the behavior you would get at the call site. Sam On Mar 13, 2011, at 4:12 AM, Steven Simpson wrote: > On 10/03/11 13:57, R?mi Forax wrote: >> Yes, we need to provide methods that filter/map directly >> the content of a collections. >> But I don't think it's a good idea to name them filter or map. >> >> Why not filterAll and mapAll ? > > I'm starting to lose track of this thread, but I recall the following > points: > > * Lazy operations are desirable, as are eager ones, and in-place ones. > * There could be a type or family thereof for lazy collections, e.g. > Stream or Iterable. > * Collections currently don't have methods for generating new > collections, so adding them is a considerable shift. They do have > in-place methods, and new methods like 'filter' share the same > tense, suggesting that they should be in-place methods too. > > In case it hasn't yet been mentioned, I'd like to add that collections > also support /views/ in several places, e.g. subList, entrySet, etc. Do > we need a lazy type when we can have views? I haven't pinned it down in > my mind yet, but I suspect that views are slightly different to streams, > in that they also allow us to modify the original collection. Or, to > put it another way, they differ from mutating methods, in that we can > choose not to perform any mutation. > > When we want to delete a portion of a list, we write: > > list.subList(a, b).clear() > > ...because the sublist view allows us to modify the original list. But > if we want to extract a sublist, and leave the original untouched, we write: > > new ArrayList(list.subList(a, b)) > > List.subList could be regarded as lazy, until we apply a mutating method > to it like clear(). And if we never do that, it stays lazy even while > we do an eager copy. > > Can we do the same with filter (using a noun like "selection" to be > consistent with subList)? > > list.selection(pred).clear(); // mutating original; removeAll(pred)? > new ArrayList(list.selection(pred)); // preserving original > > Views, having ordinary collection types, remain Iterable too: > > for (Element elem : list.selection(pred)) { ... } > > I suppose my point is that there is already a precedent for (mutable) > laziness in the collection framework, in the form of views. > > Cheers, > > Steven > > -- > > > > From forax at univ-mlv.fr Sun Mar 13 12:39:40 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Sun, 13 Mar 2011 20:39:40 +0100 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7CA697.7080300@comp.lancs.ac.uk> <4D7CAC22.9020901@univ-mlv.fr> Message-ID: <4D7D1D7C.1090409@univ-mlv.fr> On 03/13/2011 04:37 PM, Colin Decker wrote: > Set.filter() can return a Set view and List.map() can return a List > view. Of course, Set.map() can't very well return a Set view. Thanks for the correction. I was thinking Set.map() but write Set.filter(). Also it's useful to note that list.subList() return a random access list if the list is a random access list. This is not true for List.map(). > > -- > Colin R?mi From forax at univ-mlv.fr Sun Mar 13 12:47:37 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sun, 13 Mar 2011 20:47:37 +0100 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7CA697.7080300@comp.lancs.ac.uk> Message-ID: <4D7D1F59.90100@univ-mlv.fr> asStream() is not required at all. The question is more, should we mix lazy and eager method in the same interface or not. If the answer is No. asStream() is a way to specify that you want to go to the lazy world. If the answer is Yes. asStream is not needed and basically all static methods can goes into their interface as extension method. R?mi On 03/13/2011 08:01 PM, Sam Pullara wrote: > For the last year or so I have been using the Google Collections library, now distributed as part of Guava. It has most of the APIs that we are talking about and I think that regular Java programmers are using them. They separate out Lists, Iterables, Sets, Maps, Collections and Iterators. Most of the code that I have written would work great with the methods in these classes added as extension methods to the normal APIs. Function literals would of course slot right in. Here are some links to their APIs: > > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Iterables.html > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Iterators.html > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Lists.html > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Sets.html > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Maps.html > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Collections2.html > > My understanding is that they have an advantage over extension methods in the caller determines how to treat the target collection. For example, if you use: > > public class Iterables { > public static Iterable transform(Iterable fromIterable, Function function)... > } > > You get streaming behavior whereas the equivalent in Lists is evaluated eagerly: > > public class Lists { > public static List transform(List fromList, Function function) > } > > Apparently with extension methods we don't have this luxury as the type at the call site does not pick the extension method default but instead the underlying implementation does. Because of this it appears that the current proposals for things like .asStream() will actually end up being more verbose than using their Guava counterparts once function literals are available. As for the naming conventions, Guava went with filter/transform. Personally, I renamed them f/t since chaining together several in Guava gets a little silly with such long names since they show up next to one another. Here is some current code of mine: > > return l(t(f(s.bagService.featured(0, 30L, category), new P>() { > public boolean apply(@Nullable Row input) { > return input != null&& ids.add(input.value.owner()); > } > }), new F, BagCodeFactory.BagCode>() { > public BagCodeFactory.BagCode apply(Row input) { > return new BagCodeFactory(s).getBag(page, input); > } > }), count); > > l = limit, t = transform, f = filter > > In JDK8 with function literals it would look like (featured() returns an Iterable): > > return l(t(f(s.bagService.featured(0, 30L, category), #{ input -> input != null&& ids.add(input.value.owner())}), > #{ input -> new BagCodeFactory(s).getBag(page, input)}), count); > > Now, using some of the suggestions on the list so far, it could look like: > > return s.bagService.featured(0, 30L, category).asStream().fiter(#{ input -> input != null&& ids.add(input.value.owner())}) > .transform(#{ input -> new BagCodeFactory(s).getBag(page, input)}).limit(count); > > Which isn't too bad though since featured() is already returning an Iterable it feels redundant to asStream() it especially since it really is an Iterable only and doesn't use an underlying Java collection at all. It concerns me that the call site can't control behavior through typing. If we only put the extension methods on Iterable/Iterator it would be pretty easy for the developer to see that the operations are lazy and there would never be any confusion as to the behavior you would get at the call site. > > Sam > > On Mar 13, 2011, at 4:12 AM, Steven Simpson wrote: > >> On 10/03/11 13:57, R?mi Forax wrote: >>> Yes, we need to provide methods that filter/map directly >>> the content of a collections. >>> But I don't think it's a good idea to name them filter or map. >>> >>> Why not filterAll and mapAll ? >> I'm starting to lose track of this thread, but I recall the following >> points: >> >> * Lazy operations are desirable, as are eager ones, and in-place ones. >> * There could be a type or family thereof for lazy collections, e.g. >> Stream or Iterable. >> * Collections currently don't have methods for generating new >> collections, so adding them is a considerable shift. They do have >> in-place methods, and new methods like 'filter' share the same >> tense, suggesting that they should be in-place methods too. >> >> In case it hasn't yet been mentioned, I'd like to add that collections >> also support /views/ in several places, e.g. subList, entrySet, etc. Do >> we need a lazy type when we can have views? I haven't pinned it down in >> my mind yet, but I suspect that views are slightly different to streams, >> in that they also allow us to modify the original collection. Or, to >> put it another way, they differ from mutating methods, in that we can >> choose not to perform any mutation. >> >> When we want to delete a portion of a list, we write: >> >> list.subList(a, b).clear() >> >> ...because the sublist view allows us to modify the original list. But >> if we want to extract a sublist, and leave the original untouched, we write: >> >> new ArrayList(list.subList(a, b)) >> >> List.subList could be regarded as lazy, until we apply a mutating method >> to it like clear(). And if we never do that, it stays lazy even while >> we do an eager copy. >> >> Can we do the same with filter (using a noun like "selection" to be >> consistent with subList)? >> >> list.selection(pred).clear(); // mutating original; removeAll(pred)? >> new ArrayList(list.selection(pred)); // preserving original >> >> Views, having ordinary collection types, remain Iterable too: >> >> for (Element elem : list.selection(pred)) { ... } >> >> I suppose my point is that there is already a precedent for (mutable) >> laziness in the collection framework, in the form of views. >> >> Cheers, >> >> Steven >> >> -- >> >> >> >> > From sam at sampullara.com Sun Mar 13 13:15:19 2011 From: sam at sampullara.com (Sam Pullara) Date: Sun, 13 Mar 2011 13:15:19 -0700 Subject: Design for collections upgrades In-Reply-To: <4D7D1F59.90100@univ-mlv.fr> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7CA697.7080300@comp.lancs.ac.uk> <4D7D1F59.90100@univ-mlv.fr> Message-ID: If we name List.filter() and Iterable.filter() the same thing there will be no way to get to the default lazy version of filter() on a List even if the Iterable version of filter() is lazy without either naming the methods differently or requiring something that changes a List into something that doesn't implement List but does implement Iterable or another streaming interface. Am I missing something? One solution might be to put those methods on Iterator and require .iterator() (simply another name for .asStream() really). This would be kind of nice in that the for() loop would now use the lazy versions by default. Higher-level question: Does anyone really think that developers should use the eager versions or are we putting them in there as some kind of idiot proof implementation? Sam On Mar 13, 2011, at 12:47 PM, R?mi Forax wrote: > asStream() is not required at all. > > The question is more, should we mix lazy and eager method in the same > interface or not. > If the answer is No. asStream() is a way to specify that you want to go > to the lazy world. > If the answer is Yes. asStream is not needed and basically all static > methods can goes into their > interface as extension method. > > R?mi > > > On 03/13/2011 08:01 PM, Sam Pullara wrote: >> For the last year or so I have been using the Google Collections library, now distributed as part of Guava. It has most of the APIs that we are talking about and I think that regular Java programmers are using them. They separate out Lists, Iterables, Sets, Maps, Collections and Iterators. Most of the code that I have written would work great with the methods in these classes added as extension methods to the normal APIs. Function literals would of course slot right in. Here are some links to their APIs: >> >> http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Iterables.html >> http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Iterators.html >> http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Lists.html >> http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Sets.html >> http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Maps.html >> http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Collections2.html >> >> My understanding is that they have an advantage over extension methods in the caller determines how to treat the target collection. For example, if you use: >> >> public class Iterables { >> public static Iterable transform(Iterable fromIterable, Function function)... >> } >> >> You get streaming behavior whereas the equivalent in Lists is evaluated eagerly: >> >> public class Lists { >> public static List transform(List fromList, Function function) >> } >> >> Apparently with extension methods we don't have this luxury as the type at the call site does not pick the extension method default but instead the underlying implementation does. Because of this it appears that the current proposals for things like .asStream() will actually end up being more verbose than using their Guava counterparts once function literals are available. As for the naming conventions, Guava went with filter/transform. Personally, I renamed them f/t since chaining together several in Guava gets a little silly with such long names since they show up next to one another. Here is some current code of mine: >> >> return l(t(f(s.bagService.featured(0, 30L, category), new P>() { >> public boolean apply(@Nullable Row input) { >> return input != null&& ids.add(input.value.owner()); >> } >> }), new F, BagCodeFactory.BagCode>() { >> public BagCodeFactory.BagCode apply(Row input) { >> return new BagCodeFactory(s).getBag(page, input); >> } >> }), count); >> >> l = limit, t = transform, f = filter >> >> In JDK8 with function literals it would look like (featured() returns an Iterable): >> >> return l(t(f(s.bagService.featured(0, 30L, category), #{ input -> input != null&& ids.add(input.value.owner())}), >> #{ input -> new BagCodeFactory(s).getBag(page, input)}), count); >> >> Now, using some of the suggestions on the list so far, it could look like: >> >> return s.bagService.featured(0, 30L, category).asStream().fiter(#{ input -> input != null&& ids.add(input.value.owner())}) >> .transform(#{ input -> new BagCodeFactory(s).getBag(page, input)}).limit(count); >> >> Which isn't too bad though since featured() is already returning an Iterable it feels redundant to asStream() it especially since it really is an Iterable only and doesn't use an underlying Java collection at all. It concerns me that the call site can't control behavior through typing. If we only put the extension methods on Iterable/Iterator it would be pretty easy for the developer to see that the operations are lazy and there would never be any confusion as to the behavior you would get at the call site. >> >> Sam >> >> On Mar 13, 2011, at 4:12 AM, Steven Simpson wrote: >> >>> On 10/03/11 13:57, R?mi Forax wrote: >>>> Yes, we need to provide methods that filter/map directly >>>> the content of a collections. >>>> But I don't think it's a good idea to name them filter or map. >>>> >>>> Why not filterAll and mapAll ? >>> I'm starting to lose track of this thread, but I recall the following >>> points: >>> >>> * Lazy operations are desirable, as are eager ones, and in-place ones. >>> * There could be a type or family thereof for lazy collections, e.g. >>> Stream or Iterable. >>> * Collections currently don't have methods for generating new >>> collections, so adding them is a considerable shift. They do have >>> in-place methods, and new methods like 'filter' share the same >>> tense, suggesting that they should be in-place methods too. >>> >>> In case it hasn't yet been mentioned, I'd like to add that collections >>> also support /views/ in several places, e.g. subList, entrySet, etc. Do >>> we need a lazy type when we can have views? I haven't pinned it down in >>> my mind yet, but I suspect that views are slightly different to streams, >>> in that they also allow us to modify the original collection. Or, to >>> put it another way, they differ from mutating methods, in that we can >>> choose not to perform any mutation. >>> >>> When we want to delete a portion of a list, we write: >>> >>> list.subList(a, b).clear() >>> >>> ...because the sublist view allows us to modify the original list. But >>> if we want to extract a sublist, and leave the original untouched, we write: >>> >>> new ArrayList(list.subList(a, b)) >>> >>> List.subList could be regarded as lazy, until we apply a mutating method >>> to it like clear(). And if we never do that, it stays lazy even while >>> we do an eager copy. >>> >>> Can we do the same with filter (using a noun like "selection" to be >>> consistent with subList)? >>> >>> list.selection(pred).clear(); // mutating original; removeAll(pred)? >>> new ArrayList(list.selection(pred)); // preserving original >>> >>> Views, having ordinary collection types, remain Iterable too: >>> >>> for (Element elem : list.selection(pred)) { ... } >>> >>> I suppose my point is that there is already a precedent for (mutable) >>> laziness in the collection framework, in the form of views. >>> >>> Cheers, >>> >>> Steven >>> >>> -- >>> >>> >>> >>> >> > > From cmotlin at gmail.com Sun Mar 13 14:08:29 2011 From: cmotlin at gmail.com (Craig P. Motlin) Date: Sun, 13 Mar 2011 17:08:29 -0400 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7CA697.7080300@comp.lancs.ac.uk> <4D7D1F59.90100@univ-mlv.fr> Message-ID: The Scala collections framework uses eager evaluation by default and uses the .view() method to switch over to the lazy world. It seems to work well in practice. Eager evaluation should stay for performance reasons. It should stay as the *default* for the reasons Brian mentioned. Everyone assumes that lazy evaluation would usually be faster, but the Scala community has discovered that that's usually not the case (on the JVM). Of course, it will be the case if you're doing some short circuit evaluation, like find() the first element that satisfies some predicate in an already filtered list. Some performance testing is in order. On Sun, Mar 13, 2011 at 4:15 PM, Sam Pullara wrote: > If we name List.filter() and Iterable.filter() the same thing there will be > no way to get to the default lazy version of filter() on a List even if the > Iterable version of filter() is lazy without either naming the methods > differently or requiring something that changes a List into something that > doesn't implement List but does implement Iterable or another streaming > interface. Am I missing something? > > One solution might be to put those methods on Iterator and require > .iterator() (simply another name for .asStream() really). This would be kind > of nice in that the for() loop would now use the lazy versions by default. > > Higher-level question: Does anyone really think that developers should use > the eager versions or are we putting them in there as some kind of idiot > proof implementation? > > Sam > > On Mar 13, 2011, at 12:47 PM, R?mi Forax wrote: > > > asStream() is not required at all. > > > > The question is more, should we mix lazy and eager method in the same > > interface or not. > > If the answer is No. asStream() is a way to specify that you want to go > > to the lazy world. > > If the answer is Yes. asStream is not needed and basically all static > > methods can goes into their > > interface as extension method. > > > > R?mi > > > > > > On 03/13/2011 08:01 PM, Sam Pullara wrote: > >> For the last year or so I have been using the Google Collections > library, now distributed as part of Guava. It has most of the APIs that we > are talking about and I think that regular Java programmers are using them. > They separate out Lists, Iterables, Sets, Maps, Collections and Iterators. > Most of the code that I have written would work great with the methods in > these classes added as extension methods to the normal APIs. Function > literals would of course slot right in. Here are some links to their APIs: > >> > >> > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Iterables.html > >> > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Iterators.html > >> > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Lists.html > >> > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Sets.html > >> > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Maps.html > >> > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Collections2.html > >> > >> My understanding is that they have an advantage over extension methods > in the caller determines how to treat the target collection. For example, if > you use: > >> > >> public class Iterables { > >> public static Iterable transform(Iterable fromIterable, > Function function)... > >> } > >> > >> You get streaming behavior whereas the equivalent in Lists is evaluated > eagerly: > >> > >> public class Lists { > >> public static List transform(List fromList, Function super F,? extends T> function) > >> } > >> > >> Apparently with extension methods we don't have this luxury as the type > at the call site does not pick the extension method default but instead the > underlying implementation does. Because of this it appears that the current > proposals for things like .asStream() will actually end up being more > verbose than using their Guava counterparts once function literals are > available. As for the naming conventions, Guava went with filter/transform. > Personally, I renamed them f/t since chaining together several in Guava gets > a little silly with such long names since they show up next to one another. > Here is some current code of mine: > >> > >> return l(t(f(s.bagService.featured(0, 30L, category), > new P>() { > >> public boolean apply(@Nullable Row > input) { > >> return input != null&& > ids.add(input.value.owner()); > >> } > >> }), new F, BagCodeFactory.BagCode>() { > >> public BagCodeFactory.BagCode apply(Row > input) { > >> return new BagCodeFactory(s).getBag(page, input); > >> } > >> }), count); > >> > >> l = limit, t = transform, f = filter > >> > >> In JDK8 with function literals it would look like (featured() returns an > Iterable): > >> > >> return l(t(f(s.bagService.featured(0, 30L, category), #{ > input -> input != null&& ids.add(input.value.owner())}), > >> #{ input -> new BagCodeFactory(s).getBag(page, > input)}), count); > >> > >> Now, using some of the suggestions on the list so far, it could look > like: > >> > >> return s.bagService.featured(0, 30L, > category).asStream().fiter(#{ input -> input != null&& > ids.add(input.value.owner())}) > >> .transform(#{ input -> new > BagCodeFactory(s).getBag(page, input)}).limit(count); > >> > >> Which isn't too bad though since featured() is already returning an > Iterable it feels redundant to asStream() it especially since it really is > an Iterable only and doesn't use an underlying Java collection at all. It > concerns me that the call site can't control behavior through typing. If we > only put the extension methods on Iterable/Iterator it would be pretty easy > for the developer to see that the operations are lazy and there would never > be any confusion as to the behavior you would get at the call site. > >> > >> Sam > >> > >> On Mar 13, 2011, at 4:12 AM, Steven Simpson wrote: > >> > >>> On 10/03/11 13:57, R?mi Forax wrote: > >>>> Yes, we need to provide methods that filter/map directly > >>>> the content of a collections. > >>>> But I don't think it's a good idea to name them filter or map. > >>>> > >>>> Why not filterAll and mapAll ? > >>> I'm starting to lose track of this thread, but I recall the following > >>> points: > >>> > >>> * Lazy operations are desirable, as are eager ones, and in-place > ones. > >>> * There could be a type or family thereof for lazy collections, e.g. > >>> Stream or Iterable. > >>> * Collections currently don't have methods for generating new > >>> collections, so adding them is a considerable shift. They do have > >>> in-place methods, and new methods like 'filter' share the same > >>> tense, suggesting that they should be in-place methods too. > >>> > >>> In case it hasn't yet been mentioned, I'd like to add that collections > >>> also support /views/ in several places, e.g. subList, entrySet, etc. > Do > >>> we need a lazy type when we can have views? I haven't pinned it down > in > >>> my mind yet, but I suspect that views are slightly different to > streams, > >>> in that they also allow us to modify the original collection. Or, to > >>> put it another way, they differ from mutating methods, in that we can > >>> choose not to perform any mutation. > >>> > >>> When we want to delete a portion of a list, we write: > >>> > >>> list.subList(a, b).clear() > >>> > >>> ...because the sublist view allows us to modify the original list. But > >>> if we want to extract a sublist, and leave the original untouched, we > write: > >>> > >>> new ArrayList(list.subList(a, b)) > >>> > >>> List.subList could be regarded as lazy, until we apply a mutating > method > >>> to it like clear(). And if we never do that, it stays lazy even while > >>> we do an eager copy. > >>> > >>> Can we do the same with filter (using a noun like "selection" to be > >>> consistent with subList)? > >>> > >>> list.selection(pred).clear(); // mutating original; removeAll(pred)? > >>> new ArrayList(list.selection(pred)); // preserving original > >>> > >>> Views, having ordinary collection types, remain Iterable too: > >>> > >>> for (Element elem : list.selection(pred)) { ... } > >>> > >>> I suppose my point is that there is already a precedent for (mutable) > >>> laziness in the collection framework, in the form of views. > >>> > >>> Cheers, > >>> > >>> Steven > >>> > >>> -- > >>> > >>> > >>> > >>> > >> > > > > > > > From int19h at gmail.com Sun Mar 13 14:11:13 2011 From: int19h at gmail.com (Pavel Minaev) Date: Sun, 13 Mar 2011 14:11:13 -0700 Subject: Design for collections upgrades (was: Re: lambda-dev Digest, Vol 15, Issue 20 [reduce method result type]) In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> Message-ID: I think the issue is more with what type the operations produce, rather than what types they accept. If the operation accepts Iterator, then clearly you can use it with any Iterable. Now, however, I do see one strong argument against going for lazy only on Iterator (or, more generally, some kind of read-once stream abstraction). If e.g. lazy filter is only usable with iterators, then its result will necessarily have to be an Iterator, and cannot be wrapped into a proper Iterable. And now you can't use that result with an existing API that takes Iterable - and many existing ones do, even if really solely to call iterator() once on the provided value - the public contract still requires Iterable. So you wouldn't be able to use the result of lazy operations with such an API directly - you'd always have to realize it into a collection first. This is inconvenient - one neat thing about LINQ design was that it was immediately useful with numerous existing APIs. To get the same here, you'd need something like Streamable. On Sun, Mar 13, 2011 at 8:54 AM, Colin Decker wrote: > If it isn't acceptable to have lazy methods on Collections then yes, > something like "asStream()" or whatever is needed. That would cleanly > delineate the lazy operations from the eager/mutating operations and I don't > think it would be confusing. All I'm saying is that there's no need to make > the primary type that lazy operations can be used with implement the > strictly less useful Iterator when it could easily implement Iterable. > > -- > Colin > > > > On Sun, Mar 13, 2011 at 12:31 AM, Pavel Minaev wrote: > >> I argued for that as well, originally, but then operations on all >> collections would be lazy (as they are all Iterables). On the other hand, if >> specific collections override operations and redefine them as eager, we get >> an undesired inconsistency in behavior - some Iterables are lazy, while >> others are not. The best you can then do is provide some kind of >> toIterable() method on any Iterable, which would wrap it into a simple lazy >> Iterable with default implementations for map/filter/..., hiding any >> overriden behavior - and then you also have to explain to the users the >> difference between writing ((Iterable)list).map() and >> list.toIterable().map(). In contrast, iterator functions (as in, a function >> taking an iterator and returning a new iterator) are always perceived as >> lazy, whether the original iterator was obtained from a collection or not. >> >> I understand that this is not a strict argument, and it's all about what >> the API client "expects" to see, which is very subjective. But we've already >> had a lengthy argument on how to best name lazy operations such that they're >> not confused with eager operations provided by the collection itself; and >> that is mainly because the existing Java collection API is eager and >> mutable; and I see the reasons behind this argument. E.g. list.add() mutates >> the list in-place, right there and then; it does not defer the update until >> the list is iterated, nor does it create and return a new list - and so it's >> hard to argue against the claim that list.filter() should do things in an >> entirely different way. Hence the desire for some kind of >> list.magicalSomething().filter() that would clearly mark the transition to >> laziness. >> >> >> On Sat, Mar 12, 2011 at 8:37 PM, Colin Decker wrote: >> >>> Because there's no need to and because Iterables (being reusable) are far >>> more flexible than Iterators. The Iterable interface is just as lazy as >>> Iterator. The Stream interface should be Iterable. >>> >>> -- >>> Colin >>> >>> >>> >>> On Sat, Mar 12, 2011 at 11:08 PM, Pavel Minaev wrote: >>> >>>> I'm curious as to why you think that limiting lazy operations to >>>> iterators (or streams - the name is immaterial) is undesirable? In terms of >>>> code, it is exactly the same as the proposal which started the thread, with >>>> a need for one extra method call - iterator() rather than asStream() - on >>>> the collection, before you are in the lazy land. In terms of semantics, it >>>> avoids introduction of new abstractions where existing ones are sufficient >>>> to capture the intent (iterators are inherently lazy). >>>> >>>> On Sat, Mar 12, 2011 at 7:53 PM, Colin Decker wrote: >>>> >>>>> I don't feel like a comparison to InputStream etc. makes much sense >>>>> considering "Stream" is an arbitrary name that can easily be changed to >>>>> something more appropriate ("Streamable", say). I also think it's a weakness >>>>> of the IO streams that they don't have an Iterable equivalent (like >>>>> InputSupplier from Guava). Regardless, limiting lazy filter/map to Iterator >>>>> would be... undesirable. I do think Iterator should have such methods as >>>>> well, though. >>>>> >>>>> -- >>>>> Colin >>>>> >>>>> >>>>> >>>>> On Sat, Mar 12, 2011 at 8:30 PM, Pavel Minaev wrote: >>>>> >>>>>> I've been re-reading the "Design for collection upgrades" thread, and >>>>>> had >>>>>> some thoughts on the nature of the Stream abstraction (for lazy/serial >>>>>> scenario) as originally outlined in Brian's post that kicked off the >>>>>> thread, >>>>>> and users expectations of what comes with that name. >>>>>> >>>>>> Per the proposal, it sounds like Stream is more or less a marker >>>>>> interface >>>>>> to indicate lazy operations, and not otherwise any different from >>>>>> Iterable. >>>>>> However, this isn't what "stream" has historically meant in imperative >>>>>> PLs >>>>>> and their frameworks. For some examples of what I mean, let me point >>>>>> at >>>>>> java.io.InputStream, or at C++ std::basic_istream. In both cases, the >>>>>> fundamental property of the streams - the one that is guaranteed to be >>>>>> supported by _any_ stream - is that you can read elements. InputStream >>>>>> also >>>>>> offers mark()/reset(), but those are conditionally supported, and so >>>>>> are not >>>>>> part of the basic contract of the abstraction; they could (one could >>>>>> even >>>>>> argue that, from a pure OOD approach, they should) just as well be >>>>>> moved to >>>>>> a more concrete interface that could be queried by clients instead of >>>>>> using >>>>>> markSupported(). >>>>>> >>>>>> The important thing with that basic contract is that once a value is >>>>>> read >>>>>> from a stream, it stays read: a stream by itself is a read-once >>>>>> sequence. >>>>>> There may be ways to obtain another stream that would re-read the same >>>>>> exact >>>>>> elements, but that would still be a new stream object. For streams >>>>>> that wrap >>>>>> some data store (e.g. FileInputStream or ByteArrayInputStream), the >>>>>> stream >>>>>> object is essentially a cursor into the store - it has a current >>>>>> position, >>>>>> which every read advances towards the end of the store. Furthermore, >>>>>> the >>>>>> stream is not _the_ store - you can have several FileInputStreams over >>>>>> the >>>>>> same file, or several ByteArrayInputStreams sharing the same byte >>>>>> array. >>>>>> >>>>>> Now if we take the above and see how it applies to collections, it >>>>>> actually >>>>>> is a very familiar concept: something that is not a collection itself, >>>>>> but >>>>>> is a forward-only cursor for a collection, and each collection may >>>>>> have more >>>>>> than one such cursor - why, that is Iterator. Its next() and hasNext() >>>>>> methods match exactly the basic input stream contract; remove() does >>>>>> not, >>>>>> but it is conditionally-supported anyway. An analogy to highlight this >>>>>> point: Iterator is to Iterable/Collection what ByteArrayInputStream is >>>>>> to >>>>>> byte array. >>>>>> >>>>>> Iterators, being cursors, are also naturally expected to be lazy by >>>>>> API >>>>>> clients - if I provide a method that takes an iterator, applies a >>>>>> filter to >>>>>> it, and returns another iterator as a result, no-one would expect >>>>>> filtering >>>>>> to occur over the entire collection right there and then. It's clear >>>>>> that >>>>>> the result of such operation is a "filtered iterator", that would >>>>>> apply the >>>>>> filter as it is being iterated. >>>>>> >>>>>> So, then, why not put lazy map/filter/reduce/... on Iterator? Thus, >>>>>> Brian's >>>>>> original serial/lazy example would become: >>>>>> >>>>>> maxFooWeight = things.iterator() >>>>>> .filter(#Thing.isFoo) >>>>>> .map(#Thing.getWeight) >>>>>> .max(); >>>>>> >>>>>> or maybe with some less concise but more descriptive (and - purely >>>>>> subjectively - "Java-like") names: >>>>>> >>>>>> maxFooWeight = things.iterator() >>>>>> .withFilter(#Thing.isFoo) >>>>>> .withTransform(#Thing.getWeight) >>>>>> .getLargestValue(); >>>>>> >>>>>> This has a nice property of working with a more fundamental >>>>>> abstraction than >>>>>> collections - I can write an Iterator that wraps a non-rewindable I/O >>>>>> InputStream, but I cannot write such an Iterable (well, I can - if it >>>>>> throws >>>>>> after the first call to iterator() - but it will only be usable with >>>>>> APIs >>>>>> which specify that they only call iterator() on the provided Iterable >>>>>> once >>>>>> as part of their public contract; otherwise, I'm relying on an >>>>>> implementation detail). >>>>>> >>>>>> The only major annoyance I can see with this approach is that >>>>>> enhanced-for-loop only supports Iterables (and arrays) but not >>>>>> Iterators, >>>>>> and so you'd have to write a manual loop with next()/hasNext() to >>>>>> iterate >>>>>> over the result. But is there any reason why enhanced-for cannot be >>>>>> made to >>>>>> support Iterators directly? The only thing it does to the provided >>>>>> Iterable >>>>>> is to call iterator() on it, and it does it exactly once; it would >>>>>> just need >>>>>> to use the provided Iterator directly instead. It sounds like it would >>>>>> be >>>>>> trivial to add. >>>>>> >>>>>> >>>>>> The above didn't touch on what the design would look like for eager or >>>>>> lazy/parallel operations. For parallel, the original design can be >>>>>> trivially >>>>>> adapted by moving asParallel() to Iterator directly, and producing >>>>>> some sort >>>>>> of ParallelIterator, which is simply a marker interface to enable >>>>>> parallelization for all applied operations, but otherwise is the same >>>>>> as >>>>>> Iterator (probably just extending it). >>>>>> >>>>>> For eager operations, I would prefer in-place mutating methods >>>>>> returning the >>>>>> receiver (to permit chaining), with distinct but obviously mapped >>>>>> names. For >>>>>> example, if Iterator has withFilter(), then Collection would have >>>>>> filter(). >>>>>> I don't think there is much utility in having eager ops that do a >>>>>> copy, and >>>>>> even less so for chaining such. I think a simple addition of something >>>>>> like >>>>>> clone() to Collection (default implementation could do newInstance() >>>>>> assuming a no-arg constructor available, and then addAll(this) on that >>>>>> new >>>>>> instance) would cover vast majority of all cases where you want to get >>>>>> a >>>>>> copy: the usual pattern would then be to do something like: >>>>>> >>>>>> Collection getWeights() { >>>>>> return things.clone().filter(#Thing.isFoo). >>>>>> transform(#Thing.getWeight); >>>>>> } >>>>>> >>>>>> where both filter() and map() operate in-place on the cloned >>>>>> collection. >>>>>> This also skirts the whole question of the type of the resulting >>>>>> collection >>>>>> produced by a copying operation - it's clear and unambiguous what >>>>>> it'll be >>>>>> for clone(), and no other operation makes a copy. >>>>>> >>>>>> >>>>>> On Tue, Mar 8, 2011 at 9:23 AM, Brian Goetz >>>>>> wrote: >>>>>> >>>>>> > Since people are already discussing this based on an experimental >>>>>> > checkin, let me outline the big picture plan here. >>>>>> > >>>>>> > The general idea is to add functional-like operations to collections >>>>>> -- >>>>>> > filter, map, reduce, apply. >>>>>> > >>>>>> > I see three sensible modes, with explicit choices of which you get. >>>>>> > >>>>>> > 1. Serial / Eager. This is the straight >>>>>> > collections-with-functional-style mode, and some samples have >>>>>> already >>>>>> > been checked in as proof of concept. Operations on collections >>>>>> yield >>>>>> > new collections, and you can chain the calls. It values ease of use >>>>>> > over performance (no new concepts like laziness), but the >>>>>> performance >>>>>> > model is still highly predictable. You get things like >>>>>> > >>>>>> > Collection fooAbles = things.filter( #{ t -> t.isFoo() }); >>>>>> > >>>>>> > or, with method references: >>>>>> > >>>>>> > Collection fooAbles = things.filter(#Thing.isFoo); // ooh, >>>>>> pretty >>>>>> > >>>>>> > You can also chain calls together, though you pay a (predictable) >>>>>> > performance cost of intermediate collections, which for small >>>>>> > collections is unlikely to matter: >>>>>> > >>>>>> > maxFooWeight = things.filter(#Thing.isFoo) >>>>>> > .map(#Thing.getWeight) >>>>>> > .max(); >>>>>> > >>>>>> > The benefit here is concision and clarity. The cost is some >>>>>> > performance, but maybe not so much that people freak out. If people >>>>>> > care, they move to the next model, which is: >>>>>> > >>>>>> > 2. Serial / Lazy. Here, the primary abstraction is Stream (name to >>>>>> be >>>>>> > chosen later, Remi used "lazy" in his example.) To transfer between >>>>>> > "eager world" and "lazy world", you use conversion methods (toStream >>>>>> / >>>>>> > toCollection). A typical call chain probably looks like: >>>>>> > collection.toStream / op / op / op / {toCollection,reduce,apply} >>>>>> > >>>>>> > so the above example becomes >>>>>> > >>>>>> > maxFooWeight = things.asStream() >>>>>> > .filter(#Thing.isFoo) >>>>>> > .map(#Thing.getWeight) >>>>>> > .max(); >>>>>> > >>>>>> > The return type of Collection.filter is different from the return >>>>>> type >>>>>> > of Stream.filter, so the choice and performance costs are reflected >>>>>> in >>>>>> > the static type system. This avoids the cost of the intermediate >>>>>> > collections, but is still serial. If you care about that, you move >>>>>> up >>>>>> > to the next model, which is: >>>>>> > >>>>>> > 3. Parallel / Lazy. Here, the primary abstraction is something >>>>>> like >>>>>> > ParallelStream or ParallelIterable. Let's call it ParallelFoo to >>>>>> avoid >>>>>> > bikeshedding for the moment. Now, the code looks like: >>>>>> > >>>>>> > maxFooWeight = things.asParallelFoo() >>>>>> > .filter(#Thing.isFoo) >>>>>> > .map(#Thing.getWeight) >>>>>> > .max(); >>>>>> > >>>>>> > Again, the return type of ParallelFoo.filter is different from >>>>>> > Stream.filter or Collection.filter, so again the choice is reflected >>>>>> in >>>>>> > the static type system. But you don't have to rewrite your code. >>>>>> > >>>>>> > The beauty here is twofold: >>>>>> > >>>>>> > - The base model (serial/eager) is easy to understand and natural >>>>>> to >>>>>> > use as a way of expressing what the programmer wants to do, and >>>>>> > attractive enough to stand on its own -- just a little slow with big >>>>>> > collections. >>>>>> > - Switching between execution models is mostly a matter of adding >>>>>> an >>>>>> > explicit conversion or two in the call chain, as the models are >>>>>> similar >>>>>> > enough that the rest of the code should still work (and even mean >>>>>> the >>>>>> > same thing.) >>>>>> > >>>>>> > >>>>>> > On 3/8/2011 8:43 AM, R?mi Forax wrote: >>>>>> > > Le 08/03/2011 14:31, Jim Mayer a ?crit : >>>>>> > >> // I can tolerate this one >>>>>> > >> long product(List list) { >>>>>> > >> return list.map(#{x -> (long) x}).reduce(0L, #{sum, x >>>>>> -> sum >>>>>> > * x}); >>>>>> > >> } >>>>>> > > >>>>>> > > I prefer this one: >>>>>> > > >>>>>> > > long product(List list) { >>>>>> > > return list.lazy().map(#{x -> (long) x}).reduce(0L, >>>>>> #{sum, x -> >>>>>> > sum * x}); >>>>>> > > } >>>>>> > > >>>>>> > > lazy() means, don't do map directly, but wait and do map and >>>>>> reduce in >>>>>> > > one iteration. >>>>>> > > >>>>>> > > R?mi >>>>>> > > >>>>>> > > >>>>>> > >>>>>> > >>>>>> >>>>>> >>>>> >>>> >>> >> > From int19h at gmail.com Sun Mar 13 14:18:43 2011 From: int19h at gmail.com (Pavel Minaev) Date: Sun, 13 Mar 2011 14:18:43 -0700 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7CA697.7080300@comp.lancs.ac.uk> <4D7D1F59.90100@univ-mlv.fr> Message-ID: Note that the notion of "default" type implies that operations are named the same. If names themselves clearly express the difference, then neither is default, really. I think the concern isn't so much that lazy will be faster, but rather that semantics of eager and lazy (not just perf, but also things like when exceptions get thrown) are different enough that it should be obvious in code which is which. On Sun, Mar 13, 2011 at 2:08 PM, Craig P. Motlin wrote: > The Scala collections framework uses eager evaluation by default and uses > the .view() method to switch over to the lazy world. It seems to work well > in practice. > > Eager evaluation should stay for performance reasons. It should stay as the > *default* for the reasons Brian mentioned. Everyone assumes that lazy > evaluation would usually be faster, but the Scala community has discovered > that that's usually not the case (on the JVM). Of course, it will be the > case if you're doing some short circuit evaluation, like find() the first > element that satisfies some predicate in an already filtered list. Some > performance testing is in order. > > On Sun, Mar 13, 2011 at 4:15 PM, Sam Pullara wrote: > > > If we name List.filter() and Iterable.filter() the same thing there will > be > > no way to get to the default lazy version of filter() on a List even if > the > > Iterable version of filter() is lazy without either naming the methods > > differently or requiring something that changes a List into something > that > > doesn't implement List but does implement Iterable or another streaming > > interface. Am I missing something? > > > > One solution might be to put those methods on Iterator and require > > .iterator() (simply another name for .asStream() really). This would be > kind > > of nice in that the for() loop would now use the lazy versions by > default. > > > > Higher-level question: Does anyone really think that developers should > use > > the eager versions or are we putting them in there as some kind of idiot > > proof implementation? > > > > Sam > > > > On Mar 13, 2011, at 12:47 PM, R?mi Forax wrote: > > > > > asStream() is not required at all. > > > > > > The question is more, should we mix lazy and eager method in the same > > > interface or not. > > > If the answer is No. asStream() is a way to specify that you want to go > > > to the lazy world. > > > If the answer is Yes. asStream is not needed and basically all static > > > methods can goes into their > > > interface as extension method. > > > > > > R?mi > > > > > > > > > On 03/13/2011 08:01 PM, Sam Pullara wrote: > > >> For the last year or so I have been using the Google Collections > > library, now distributed as part of Guava. It has most of the APIs that > we > > are talking about and I think that regular Java programmers are using > them. > > They separate out Lists, Iterables, Sets, Maps, Collections and > Iterators. > > Most of the code that I have written would work great with the methods in > > these classes added as extension methods to the normal APIs. Function > > literals would of course slot right in. Here are some links to their > APIs: > > >> > > >> > > > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Iterables.html > > >> > > > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Iterators.html > > >> > > > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Lists.html > > >> > > > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Sets.html > > >> > > > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Maps.html > > >> > > > http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/Collections2.html > > >> > > >> My understanding is that they have an advantage over extension methods > > in the caller determines how to treat the target collection. For example, > if > > you use: > > >> > > >> public class Iterables { > > >> public static Iterable transform(Iterable fromIterable, > > Function function)... > > >> } > > >> > > >> You get streaming behavior whereas the equivalent in Lists is > evaluated > > eagerly: > > >> > > >> public class Lists { > > >> public static List transform(List fromList, Function > super F,? extends T> function) > > >> } > > >> > > >> Apparently with extension methods we don't have this luxury as the > type > > at the call site does not pick the extension method default but instead > the > > underlying implementation does. Because of this it appears that the > current > > proposals for things like .asStream() will actually end up being more > > verbose than using their Guava counterparts once function literals are > > available. As for the naming conventions, Guava went with > filter/transform. > > Personally, I renamed them f/t since chaining together several in Guava > gets > > a little silly with such long names since they show up next to one > another. > > Here is some current code of mine: > > >> > > >> return l(t(f(s.bagService.featured(0, 30L, category), > > new P>() { > > >> public boolean apply(@Nullable Row > > input) { > > >> return input != null&& > > ids.add(input.value.owner()); > > >> } > > >> }), new F, BagCodeFactory.BagCode>() > { > > >> public BagCodeFactory.BagCode apply(Row > > input) { > > >> return new BagCodeFactory(s).getBag(page, input); > > >> } > > >> }), count); > > >> > > >> l = limit, t = transform, f = filter > > >> > > >> In JDK8 with function literals it would look like (featured() returns > an > > Iterable): > > >> > > >> return l(t(f(s.bagService.featured(0, 30L, category), > #{ > > input -> input != null&& ids.add(input.value.owner())}), > > >> #{ input -> new BagCodeFactory(s).getBag(page, > > input)}), count); > > >> > > >> Now, using some of the suggestions on the list so far, it could look > > like: > > >> > > >> return s.bagService.featured(0, 30L, > > category).asStream().fiter(#{ input -> input != null&& > > ids.add(input.value.owner())}) > > >> .transform(#{ input -> new > > BagCodeFactory(s).getBag(page, input)}).limit(count); > > >> > > >> Which isn't too bad though since featured() is already returning an > > Iterable it feels redundant to asStream() it especially since it really > is > > an Iterable only and doesn't use an underlying Java collection at all. It > > concerns me that the call site can't control behavior through typing. If > we > > only put the extension methods on Iterable/Iterator it would be pretty > easy > > for the developer to see that the operations are lazy and there would > never > > be any confusion as to the behavior you would get at the call site. > > >> > > >> Sam > > >> > > >> On Mar 13, 2011, at 4:12 AM, Steven Simpson wrote: > > >> > > >>> On 10/03/11 13:57, R?mi Forax wrote: > > >>>> Yes, we need to provide methods that filter/map directly > > >>>> the content of a collections. > > >>>> But I don't think it's a good idea to name them filter or map. > > >>>> > > >>>> Why not filterAll and mapAll ? > > >>> I'm starting to lose track of this thread, but I recall the following > > >>> points: > > >>> > > >>> * Lazy operations are desirable, as are eager ones, and in-place > > ones. > > >>> * There could be a type or family thereof for lazy collections, > e.g. > > >>> Stream or Iterable. > > >>> * Collections currently don't have methods for generating new > > >>> collections, so adding them is a considerable shift. They do > have > > >>> in-place methods, and new methods like 'filter' share the same > > >>> tense, suggesting that they should be in-place methods too. > > >>> > > >>> In case it hasn't yet been mentioned, I'd like to add that > collections > > >>> also support /views/ in several places, e.g. subList, entrySet, etc. > > Do > > >>> we need a lazy type when we can have views? I haven't pinned it down > > in > > >>> my mind yet, but I suspect that views are slightly different to > > streams, > > >>> in that they also allow us to modify the original collection. Or, to > > >>> put it another way, they differ from mutating methods, in that we can > > >>> choose not to perform any mutation. > > >>> > > >>> When we want to delete a portion of a list, we write: > > >>> > > >>> list.subList(a, b).clear() > > >>> > > >>> ...because the sublist view allows us to modify the original list. > But > > >>> if we want to extract a sublist, and leave the original untouched, we > > write: > > >>> > > >>> new ArrayList(list.subList(a, b)) > > >>> > > >>> List.subList could be regarded as lazy, until we apply a mutating > > method > > >>> to it like clear(). And if we never do that, it stays lazy even > while > > >>> we do an eager copy. > > >>> > > >>> Can we do the same with filter (using a noun like "selection" to be > > >>> consistent with subList)? > > >>> > > >>> list.selection(pred).clear(); // mutating original; removeAll(pred)? > > >>> new ArrayList(list.selection(pred)); // preserving original > > >>> > > >>> Views, having ordinary collection types, remain Iterable too: > > >>> > > >>> for (Element elem : list.selection(pred)) { ... } > > >>> > > >>> I suppose my point is that there is already a precedent for (mutable) > > >>> laziness in the collection framework, in the form of views. > > >>> > > >>> Cheers, > > >>> > > >>> Steven > > >>> > > >>> -- > > >>> > > >>> > > >>> > > >>> > > >> > > > > > > > > > > > > > > From cgdecker at gmail.com Sun Mar 13 14:42:24 2011 From: cgdecker at gmail.com (Colin Decker) Date: Sun, 13 Mar 2011 17:42:24 -0400 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7CA697.7080300@comp.lancs.ac.uk> Message-ID: On Sun, Mar 13, 2011 at 3:01 PM, Sam Pullara wrote: > the equivalent in Lists is evaluated eagerly Guava's Lists.transform is lazy just like Iterables.transform. A lazy transformed List has the same size as the List it's based on and indexed access works the same as well. On Sun, Mar 13, 2011 at 3:39 PM, R?mi Forax wrote: > Also it's useful to note that list.subList() return a random access list if the list is a random access list. > This is not true for List.map(). I don't see any reason List.map() couldn't return a random access list if the list is random access as well. Lists.transform does that, for example. -- Colin From forax at univ-mlv.fr Sun Mar 13 15:37:35 2011 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Sun, 13 Mar 2011 23:37:35 +0100 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7CA697.7080300@comp.lancs.ac.uk> Message-ID: <4D7D472F.5070009@univ-mlv.fr> On 03/13/2011 10:42 PM, Colin Decker wrote: > On Sun, Mar 13, 2011 at 3:39 PM, R?mi Forax wrote: >> Also it's useful to note that list.subList() return a random access list > if the list is a random access list. >> This is not true for List.map(). > I don't see any reason List.map() couldn't return a random access list if > the list is random access as well. Lists.transform does that, for example. > I mean List.filter() ... R?mi PS: for today s/filter/map and s/map/filter From forax at univ-mlv.fr Sun Mar 13 16:01:47 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 14 Mar 2011 00:01:47 +0100 Subject: Design for collections upgrades In-Reply-To: References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7CA697.7080300@comp.lancs.ac.uk> <4D7D1F59.90100@univ-mlv.fr> Message-ID: <4D7D4CDB.7050505@univ-mlv.fr> On 03/13/2011 09:15 PM, Sam Pullara wrote: > If we name List.filter() and Iterable.filter() the same thing there will be no way to get to the default lazy version of filter() on a List even if the Iterable version of filter() is lazy without either naming the methods differently or requiring something that changes a List into something that doesn't implement List but does implement Iterable or another streaming interface. Am I missing something? if Iterable.filter() is lazy, List.filter() must be lazy. overridden method should never change the semantics. > One solution might be to put those methods on Iterator and require .iterator() (simply another name for .asStream() really). This would be kind of nice in that the for() loop would now use the lazy versions by default. iterator() is not equivalent to asStream() if we want to be able to iterate several time on the same filtered collection. > Higher-level question: Does anyone really think that developers should use the eager versions or are we putting them in there as some kind of idiot proof implementation? Eager in-place versions are useful. I don't know for the other versions. > Sam R?mi From scolebourne at joda.org Sun Mar 13 16:27:20 2011 From: scolebourne at joda.org (Stephen Colebourne) Date: Sun, 13 Mar 2011 23:27:20 +0000 Subject: Design for collections upgrades In-Reply-To: <4D7CFCC2.6060209@oracle.com> References: <4D763295.7000708@univ-mlv.fr> <4D7665FB.5070209@oracle.com> <4D76869C.7010203@univ-mlv.fr> <4D78D8CB.4020801@univ-mlv.fr> <4D7923E6.1010601@oracle.com> <4D7CFCC2.6060209@oracle.com> Message-ID: On 13 March 2011 17:20, Brian Goetz wrote: >> I suggest that in-place operations, if included, should be named something like >> >> void Collection.retainAll(Predicate ?predicate); >> void Collection.removeAll(Predicate ?predicate); > > Which, conveniently, coincides exactly with our intent. ?Map and reduce > do not make sense as in-place operations, so really the whole in-place > thing is about filtering, for which we already have sensible names > (retainAll/removeAll) that are just crying out for lambda versions. Great! retainAll/removeAll with lambdas FTW! On the rest, I've not made a conclusion yet as to the usability of the API. Stephen From peter.levart at marand.si Mon Mar 14 01:07:52 2011 From: peter.levart at marand.si (Peter Levart) Date: Mon, 14 Mar 2011 09:07:52 +0100 Subject: Design for collections upgrades In-Reply-To: <4D78D96F.4070907@univ-mlv.fr> References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> Message-ID: <201103140907.52816.peter.levart@marand.si> On 03/10/11, R?mi Forax wrote: > Le 10/03/2011 13:10, Peter Levart a ?crit : > > Let Iterable by default (via defender methods) be lazy but let Collection (also via defender methods) override the same methods an make them eager. Also privide two methods to switch between eager and lazy on the Iterable itself (and override in Collection and subtypes). > > If Collection.filter overrides Iterable.filter, they should have the > same semantics. > And as I already say, how to implement toEager() ? Now after more discussion on the list, I'm not supporting my suggestion any further. But I'm not keen on a new "Stream" type either. The original fear that lazy evaluation of filtering/mapping/reducing/etc... operations on collections would feel unnatural to casual programmer, because collections library is currently not using any form of lazy evaluation is, I think, at least partialy unfounded. Lazy evaluation of operations on collection can be described as having two subtle semantic properties: 1. The evaluation of predicates, mappers, reducers, etc. happens at the latest possible moment, when the resulting data is requested (iterated over, collected into a propper collection, etc...) 2. The original data that is the source for the operations is stored in the source collection (the resulting Iterable is not detatched from original data - it is a transformed view over source collection). So modifying source collection before or in the middle of iteration over the result has a consequence on the result. The 2nd property is already known to users of collections library (Map.keySet(), Map.values(), ...) and therefore, if propperly documented, can not present any additional confusion. The 1st property is something new that everyone will have to learn since more and more APIs can be expected to exhibit this behaviour after lambdas are introduced to Java. Programmers will have to learn about pure functions and why they are their friends... I'm now a supporter of lazy java.lang.Iterable (and by inheritance also java.util.Collection). Overall it represents simpler and more consistent API with no need for additional Stream type. It does not exhibit problems that eager evaluation does: - what should the eager result type be and what implementation should be choosen (ArrayList/HashSet/TreeSet) - inherent sub-optimabillity (think of how easy it is to write: s = s + "xxx"; s = s + "..."; ...instead of using StringBuilder) Peter > > R?mi > > > From cmotlin at gmail.com Mon Mar 14 06:25:45 2011 From: cmotlin at gmail.com (Craig P. Motlin) Date: Mon, 14 Mar 2011 09:25:45 -0400 Subject: Design for collections upgrades In-Reply-To: <201103140907.52816.peter.levart@marand.si> References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> Message-ID: The problem is that the result of calling filter or transform on a lazy collection is another lazy collection, which makes them very hard to adopt. There's a lot of code out there that's already doing transformations like this: public List
doTransform(List people) { List
result = new ArrayList
(); for (Person person : people) { result.add(person.getAddress()); } return result; } Since it's public, it might be really hard to change the return type to a lazy collection. The same argument applies for fields. In order to use a lambda here, the code would become transform().asList(), which will be slower than the original code. And if it's slower, it will hurt adoption. There is one problem with covariant return types at compile time. It's easy for filter(), it can always be covariant. It's a little different for transform(). When you transform an ArrayList, you should get back another ArrayList by default. Sometimes people will want to collapse duplicates but you shouldn't have to create an ArrayList just to create a HashSet right afterwards. So it makes sense to have a second form of transform() and filter() that take a second argument, a mutable collection to dump their output into. HashSet.transform() should also return a HashSet by default. For TreeSet, that's impossible though. If you're starting with a TreeSet then it was constructed with some Comparator. You can't return SortedSet
from transform() because there's no Comparator
. It actually makes sense for SortedSet.transform() to return a List. Since SortedSet extends Set, there are two difficult choices. - Have Set and SortedSet both return HashSet - Have Set return Set and SortedSet return List but the static type they return is just Collection On Mon, Mar 14, 2011 at 4:07 AM, Peter Levart wrote: > On 03/10/11, R?mi Forax wrote: > > Le 10/03/2011 13:10, Peter Levart a ?crit : > > > Let Iterable by default (via defender methods) be lazy but let > Collection (also via defender methods) override the same methods an make > them eager. Also privide two methods to switch between eager and lazy on the > Iterable itself (and override in Collection and subtypes). > > > > If Collection.filter overrides Iterable.filter, they should have the > > same semantics. > > And as I already say, how to implement toEager() ? > > Now after more discussion on the list, I'm not supporting my suggestion any > further. But I'm not keen on a new "Stream" type either. The original fear > that lazy evaluation of filtering/mapping/reducing/etc... operations on > collections would feel unnatural to casual programmer, because collections > library is currently not using any form of lazy evaluation is, I think, at > least partialy unfounded. > > Lazy evaluation of operations on collection can be described as having two > subtle semantic properties: > > 1. The evaluation of predicates, mappers, reducers, etc. happens at the > latest possible moment, when the resulting data is requested (iterated over, > collected into a propper collection, etc...) > > 2. The original data that is the source for the operations is stored in the > source collection (the resulting Iterable is not detatched from original > data - it is a transformed view over source collection). So modifying source > collection before or in the middle of iteration over the result has a > consequence on the result. > > The 2nd property is already known to users of collections library > (Map.keySet(), Map.values(), ...) and therefore, if propperly documented, > can not present any additional confusion. > > The 1st property is something new that everyone will have to learn since > more and more APIs can be expected to exhibit this behaviour after lambdas > are introduced to Java. Programmers will have to learn about pure functions > and why they are their friends... > > I'm now a supporter of lazy java.lang.Iterable (and by inheritance also > java.util.Collection). Overall it represents simpler and more consistent API > with no need for additional Stream type. It does not exhibit problems that > eager evaluation does: > > - what should the eager result type be and what implementation should be > choosen (ArrayList/HashSet/TreeSet) > - inherent sub-optimabillity (think of how easy it is to write: s = s + > "xxx"; s = s + "..."; ...instead of using StringBuilder) > > Peter > > > > > R?mi > > > > > > > > From cmotlin at gmail.com Mon Mar 14 06:30:15 2011 From: cmotlin at gmail.com (Craig P. Motlin) Date: Mon, 14 Mar 2011 09:30:15 -0400 Subject: Design for collections upgrades In-Reply-To: References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> Message-ID: There are two forms of lazy evaluation and I see people using the same term (Stream) to refer to both. In Scala they are called view and stream and I was confused about the difference so I asked on Stack Overflow. Basically the difference is: In a view elements are recomputed each time they are accessed. In a stream elements are retained as they are evaluated. I think that Java collections ought to support both, which is another reason I think that eager ought to be the default. See the full explanation here: http://stackoverflow.com/questions/2282754/what-is-the-difference-between-a-view-and-a-stream On Mon, Mar 14, 2011 at 9:25 AM, Craig P. Motlin wrote: > The problem is that the result of calling filter or transform on a lazy > collection is another lazy collection, which makes them very hard to adopt. > There's a lot of code out there that's already doing transformations like > this: > > public List
doTransform(List people) > { > List
result = new ArrayList
(); > for (Person person : people) > { > result.add(person.getAddress()); > } > return result; > } > > Since it's public, it might be really hard to change the return type to a > lazy collection. The same argument applies for fields. In order to use a > lambda here, the code would become transform().asList(), which will be > slower than the original code. And if it's slower, it will hurt adoption. > > There is one problem with covariant return types at compile time. It's easy > for filter(), it can always be covariant. It's a little different for > transform(). When you transform an ArrayList, you should get back another > ArrayList by default. Sometimes people will want to collapse duplicates but > you shouldn't have to create an ArrayList just to create a HashSet right > afterwards. So it makes sense to have a second form of transform() and > filter() that take a second argument, a mutable collection to dump their > output into. HashSet.transform() should also return a HashSet by default. > For TreeSet, that's impossible though. If you're starting with a > TreeSet then it was constructed with some Comparator. You > can't return SortedSet
from transform() because there's no > Comparator
. It actually makes sense for SortedSet.transform() to > return a List. Since SortedSet extends Set, there are two difficult choices. > > - Have Set and SortedSet both return HashSet > - Have Set return Set and SortedSet return List but the static type > they return is just Collection > > > On Mon, Mar 14, 2011 at 4:07 AM, Peter Levart wrote: > >> On 03/10/11, R?mi Forax wrote: >> > Le 10/03/2011 13:10, Peter Levart a ?crit : >> > > Let Iterable by default (via defender methods) be lazy but let >> Collection (also via defender methods) override the same methods an make >> them eager. Also privide two methods to switch between eager and lazy on the >> Iterable itself (and override in Collection and subtypes). >> > >> > If Collection.filter overrides Iterable.filter, they should have the >> > same semantics. >> > And as I already say, how to implement toEager() ? >> >> Now after more discussion on the list, I'm not supporting my suggestion >> any further. But I'm not keen on a new "Stream" type either. The original >> fear that lazy evaluation of filtering/mapping/reducing/etc... operations on >> collections would feel unnatural to casual programmer, because collections >> library is currently not using any form of lazy evaluation is, I think, at >> least partialy unfounded. >> >> Lazy evaluation of operations on collection can be described as having two >> subtle semantic properties: >> >> 1. The evaluation of predicates, mappers, reducers, etc. happens at the >> latest possible moment, when the resulting data is requested (iterated over, >> collected into a propper collection, etc...) >> >> 2. The original data that is the source for the operations is stored in >> the source collection (the resulting Iterable is not detatched from original >> data - it is a transformed view over source collection). So modifying source >> collection before or in the middle of iteration over the result has a >> consequence on the result. >> >> The 2nd property is already known to users of collections library >> (Map.keySet(), Map.values(), ...) and therefore, if propperly documented, >> can not present any additional confusion. >> >> The 1st property is something new that everyone will have to learn since >> more and more APIs can be expected to exhibit this behaviour after lambdas >> are introduced to Java. Programmers will have to learn about pure functions >> and why they are their friends... >> >> I'm now a supporter of lazy java.lang.Iterable (and by inheritance also >> java.util.Collection). Overall it represents simpler and more consistent API >> with no need for additional Stream type. It does not exhibit problems that >> eager evaluation does: >> >> - what should the eager result type be and what implementation should be >> choosen (ArrayList/HashSet/TreeSet) >> - inherent sub-optimabillity (think of how easy it is to write: s = s + >> "xxx"; s = s + "..."; ...instead of using StringBuilder) >> >> Peter >> >> > >> > R?mi >> > >> > >> > >> >> > From forax at univ-mlv.fr Mon Mar 14 07:11:07 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 14 Mar 2011 15:11:07 +0100 Subject: Design for collections upgrades In-Reply-To: References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> Message-ID: <4D7E21FB.2090609@univ-mlv.fr> The corresponding code is: return people.map(#{ p -> p.getAddress() }).to(new ArrayList<>()); It create one supplementary object (the stream) compared to the code you provide and should be a little slower because currently the lambda code is not inlined into the code of map(). But if the list is not big <10 000 elements you should not notice it. R?mi On 03/14/2011 02:25 PM, Craig P. Motlin wrote: > The problem is that the result of calling filter or transform on a lazy > collection is another lazy collection, which makes them very hard to adopt. > There's a lot of code out there that's already doing transformations like > this: > > public List
doTransform(List people) > { > List
result = new ArrayList
(); > for (Person person : people) > { > result.add(person.getAddress()); > } > return result; > } > > Since it's public, it might be really hard to change the return type to a > lazy collection. The same argument applies for fields. In order to use a > lambda here, the code would become transform().asList(), which will be > slower than the original code. And if it's slower, it will hurt adoption. > > There is one problem with covariant return types at compile time. It's easy > for filter(), it can always be covariant. It's a little different for > transform(). When you transform an ArrayList, you should get back another > ArrayList by default. Sometimes people will want to collapse duplicates but > you shouldn't have to create an ArrayList just to create a HashSet right > afterwards. So it makes sense to have a second form of transform() and > filter() that take a second argument, a mutable collection to dump their > output into. HashSet.transform() should also return a HashSet by default. > For TreeSet, that's impossible though. If you're starting with a > TreeSet then it was constructed with some Comparator. You > can't return SortedSet
from transform() because there's no > Comparator
. It actually makes sense for SortedSet.transform() to > return a List. Since SortedSet extends Set, there are two difficult choices. > > - Have Set and SortedSet both return HashSet > - Have Set return Set and SortedSet return List but the static type they > return is just Collection > > > On Mon, Mar 14, 2011 at 4:07 AM, Peter Levartwrote: > >> On 03/10/11, R?mi Forax wrote: >>> Le 10/03/2011 13:10, Peter Levart a ?crit : >>>> Let Iterable by default (via defender methods) be lazy but let >> Collection (also via defender methods) override the same methods an make >> them eager. Also privide two methods to switch between eager and lazy on the >> Iterable itself (and override in Collection and subtypes). >>> If Collection.filter overrides Iterable.filter, they should have the >>> same semantics. >>> And as I already say, how to implement toEager() ? >> Now after more discussion on the list, I'm not supporting my suggestion any >> further. But I'm not keen on a new "Stream" type either. The original fear >> that lazy evaluation of filtering/mapping/reducing/etc... operations on >> collections would feel unnatural to casual programmer, because collections >> library is currently not using any form of lazy evaluation is, I think, at >> least partialy unfounded. >> >> Lazy evaluation of operations on collection can be described as having two >> subtle semantic properties: >> >> 1. The evaluation of predicates, mappers, reducers, etc. happens at the >> latest possible moment, when the resulting data is requested (iterated over, >> collected into a propper collection, etc...) >> >> 2. The original data that is the source for the operations is stored in the >> source collection (the resulting Iterable is not detatched from original >> data - it is a transformed view over source collection). So modifying source >> collection before or in the middle of iteration over the result has a >> consequence on the result. >> >> The 2nd property is already known to users of collections library >> (Map.keySet(), Map.values(), ...) and therefore, if propperly documented, >> can not present any additional confusion. >> >> The 1st property is something new that everyone will have to learn since >> more and more APIs can be expected to exhibit this behaviour after lambdas >> are introduced to Java. Programmers will have to learn about pure functions >> and why they are their friends... >> >> I'm now a supporter of lazy java.lang.Iterable (and by inheritance also >> java.util.Collection). Overall it represents simpler and more consistent API >> with no need for additional Stream type. It does not exhibit problems that >> eager evaluation does: >> >> - what should the eager result type be and what implementation should be >> choosen (ArrayList/HashSet/TreeSet) >> - inherent sub-optimabillity (think of how easy it is to write: s = s + >> "xxx"; s = s + "..."; ...instead of using StringBuilder) >> >> Peter >> >>> R?mi >>> >>> >>> >> From forax at univ-mlv.fr Mon Mar 14 07:20:28 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 14 Mar 2011 15:20:28 +0100 Subject: Design for collections upgrades In-Reply-To: References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> Message-ID: <4D7E242C.1090004@univ-mlv.fr> On 03/14/2011 02:30 PM, Craig P. Motlin wrote: > There are two forms of lazy evaluation and I see people using the same term > (Stream) to refer to both. In Scala they are called view and stream and I > was confused about the difference so I asked on Stack Overflow. Basically > the difference is: > In a view elements are recomputed each time they are accessed. In a stream > elements are retained as they are evaluated. > > I think that Java collections ought to support both, which is another reason > I think that eager ought to be the default. See the full explanation here: > http://stackoverflow.com/questions/2282754/what-is-the-difference-between-a-view-and-a-stream Interresting. But memoization is hard to provide when your original collection is mutable: What does this code print ? LinkedList list = new LinkedList<>(); Collections.addAll(list, 1, 2, 3, 4, 5); List list2 = list.asScalaStreamPlease(); System.out.println(list2.join(" ")); // the whole list is now memoized list.remove(0); // wink wink System.out.println(list2.join(" ")); R?mi From forax at univ-mlv.fr Mon Mar 14 07:36:02 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 14 Mar 2011 15:36:02 +0100 Subject: Design for collections upgrades In-Reply-To: <4676177670040766096@unknownmsgid> References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> <4D7E21FB.2090609@univ-mlv.fr> <4676177670040766096@unknownmsgid> Message-ID: <4D7E27D2.5000208@univ-mlv.fr> On 03/14/2011 03:33 PM, Sam Pullara wrote: > If we use Iterable for stream it would be the same number of objects > since the for loop is making the same object. The only real difference > is the lambda. > > Sent from my iPhone I don't follow you on this. The for loop create an iterator not an iterable. R?mi > On Mar 14, 2011, at 7:30 AM, R?mi Forax wrote: > >> The corresponding code is: >> return people.map(#{ p -> p.getAddress() }).to(new ArrayList<>()); >> >> It create one supplementary object (the stream) compared to the code you >> provide >> and should be a little slower because currently the lambda code is not >> inlined >> into the code of map(). >> But if the list is not big<10 000 elements you should not notice it. >> >> R?mi >> >> On 03/14/2011 02:25 PM, Craig P. Motlin wrote: >>> The problem is that the result of calling filter or transform on a lazy >>> collection is another lazy collection, which makes them very hard to adopt. >>> There's a lot of code out there that's already doing transformations like >>> this: >>> >>> public List
doTransform(List people) >>> { >>> List
result = new ArrayList
(); >>> for (Person person : people) >>> { >>> result.add(person.getAddress()); >>> } >>> return result; >>> } >>> >>> Since it's public, it might be really hard to change the return type to a >>> lazy collection. The same argument applies for fields. In order to use a >>> lambda here, the code would become transform().asList(), which will be >>> slower than the original code. And if it's slower, it will hurt adoption. >>> >>> There is one problem with covariant return types at compile time. It's easy >>> for filter(), it can always be covariant. It's a little different for >>> transform(). When you transform an ArrayList, you should get back another >>> ArrayList by default. Sometimes people will want to collapse duplicates but >>> you shouldn't have to create an ArrayList just to create a HashSet right >>> afterwards. So it makes sense to have a second form of transform() and >>> filter() that take a second argument, a mutable collection to dump their >>> output into. HashSet.transform() should also return a HashSet by default. >>> For TreeSet, that's impossible though. If you're starting with a >>> TreeSet then it was constructed with some Comparator. You >>> can't return SortedSet
from transform() because there's no >>> Comparator
. It actually makes sense for SortedSet.transform() to >>> return a List. Since SortedSet extends Set, there are two difficult choices. >>> >>> - Have Set and SortedSet both return HashSet >>> - Have Set return Set and SortedSet return List but the static type they >>> return is just Collection >>> >>> >>> On Mon, Mar 14, 2011 at 4:07 AM, Peter Levartwrote: >>> >>>> On 03/10/11, R?mi Forax wrote: >>>>> Le 10/03/2011 13:10, Peter Levart a ?crit : >>>>>> Let Iterable by default (via defender methods) be lazy but let >>>> Collection (also via defender methods) override the same methods an make >>>> them eager. Also privide two methods to switch between eager and lazy on the >>>> Iterable itself (and override in Collection and subtypes). >>>>> If Collection.filter overrides Iterable.filter, they should have the >>>>> same semantics. >>>>> And as I already say, how to implement toEager() ? >>>> Now after more discussion on the list, I'm not supporting my suggestion any >>>> further. But I'm not keen on a new "Stream" type either. The original fear >>>> that lazy evaluation of filtering/mapping/reducing/etc... operations on >>>> collections would feel unnatural to casual programmer, because collections >>>> library is currently not using any form of lazy evaluation is, I think, at >>>> least partialy unfounded. >>>> >>>> Lazy evaluation of operations on collection can be described as having two >>>> subtle semantic properties: >>>> >>>> 1. The evaluation of predicates, mappers, reducers, etc. happens at the >>>> latest possible moment, when the resulting data is requested (iterated over, >>>> collected into a propper collection, etc...) >>>> >>>> 2. The original data that is the source for the operations is stored in the >>>> source collection (the resulting Iterable is not detatched from original >>>> data - it is a transformed view over source collection). So modifying source >>>> collection before or in the middle of iteration over the result has a >>>> consequence on the result. >>>> >>>> The 2nd property is already known to users of collections library >>>> (Map.keySet(), Map.values(), ...) and therefore, if propperly documented, >>>> can not present any additional confusion. >>>> >>>> The 1st property is something new that everyone will have to learn since >>>> more and more APIs can be expected to exhibit this behaviour after lambdas >>>> are introduced to Java. Programmers will have to learn about pure functions >>>> and why they are their friends... >>>> >>>> I'm now a supporter of lazy java.lang.Iterable (and by inheritance also >>>> java.util.Collection). Overall it represents simpler and more consistent API >>>> with no need for additional Stream type. It does not exhibit problems that >>>> eager evaluation does: >>>> >>>> - what should the eager result type be and what implementation should be >>>> choosen (ArrayList/HashSet/TreeSet) >>>> - inherent sub-optimabillity (think of how easy it is to write: s = s + >>>> "xxx"; s = s + "..."; ...instead of using StringBuilder) >>>> >>>> Peter >>>> >>>>> R?mi >>>>> >>>>> >>>>> >> From forax at univ-mlv.fr Mon Mar 14 08:21:29 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 14 Mar 2011 16:21:29 +0100 Subject: Design for collections upgrades In-Reply-To: <-1317115006247475939@unknownmsgid> References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> <4D7E21FB.2090609@univ-mlv.fr> <4676177670040766096@unknownmsgid> <4D7E27D2.5000208@univ-mlv.fr> <-1317115006247475939@unknownmsgid> Message-ID: <4D7E3279.50102@univ-mlv.fr> On 03/14/2011 04:06 PM, Sam Pullara wrote: > Ah, the intermediate Iterable. Too early :) > > Sent from my iPhone Yes ! I've just thought that it's a good candidate for escape analysis :) R?mi From spullara at gmail.com Mon Mar 14 07:33:12 2011 From: spullara at gmail.com (Sam Pullara) Date: Mon, 14 Mar 2011 07:33:12 -0700 Subject: Design for collections upgrades In-Reply-To: <4D7E21FB.2090609@univ-mlv.fr> References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> <4D7E21FB.2090609@univ-mlv.fr> Message-ID: <4676177670040766096@unknownmsgid> If we use Iterable for stream it would be the same number of objects since the for loop is making the same object. The only real difference is the lambda. Sent from my iPhone On Mar 14, 2011, at 7:30 AM, R?mi Forax wrote: > The corresponding code is: > return people.map(#{ p -> p.getAddress() }).to(new ArrayList<>()); > > It create one supplementary object (the stream) compared to the code you > provide > and should be a little slower because currently the lambda code is not > inlined > into the code of map(). > But if the list is not big <10 000 elements you should not notice it. > > R?mi > > On 03/14/2011 02:25 PM, Craig P. Motlin wrote: >> The problem is that the result of calling filter or transform on a lazy >> collection is another lazy collection, which makes them very hard to adopt. >> There's a lot of code out there that's already doing transformations like >> this: >> >> public List
doTransform(List people) >> { >> List
result = new ArrayList
(); >> for (Person person : people) >> { >> result.add(person.getAddress()); >> } >> return result; >> } >> >> Since it's public, it might be really hard to change the return type to a >> lazy collection. The same argument applies for fields. In order to use a >> lambda here, the code would become transform().asList(), which will be >> slower than the original code. And if it's slower, it will hurt adoption. >> >> There is one problem with covariant return types at compile time. It's easy >> for filter(), it can always be covariant. It's a little different for >> transform(). When you transform an ArrayList, you should get back another >> ArrayList by default. Sometimes people will want to collapse duplicates but >> you shouldn't have to create an ArrayList just to create a HashSet right >> afterwards. So it makes sense to have a second form of transform() and >> filter() that take a second argument, a mutable collection to dump their >> output into. HashSet.transform() should also return a HashSet by default. >> For TreeSet, that's impossible though. If you're starting with a >> TreeSet then it was constructed with some Comparator. You >> can't return SortedSet
from transform() because there's no >> Comparator
. It actually makes sense for SortedSet.transform() to >> return a List. Since SortedSet extends Set, there are two difficult choices. >> >> - Have Set and SortedSet both return HashSet >> - Have Set return Set and SortedSet return List but the static type they >> return is just Collection >> >> >> On Mon, Mar 14, 2011 at 4:07 AM, Peter Levartwrote: >> >>> On 03/10/11, R?mi Forax wrote: >>>> Le 10/03/2011 13:10, Peter Levart a ?crit : >>>>> Let Iterable by default (via defender methods) be lazy but let >>> Collection (also via defender methods) override the same methods an make >>> them eager. Also privide two methods to switch between eager and lazy on the >>> Iterable itself (and override in Collection and subtypes). >>>> If Collection.filter overrides Iterable.filter, they should have the >>>> same semantics. >>>> And as I already say, how to implement toEager() ? >>> Now after more discussion on the list, I'm not supporting my suggestion any >>> further. But I'm not keen on a new "Stream" type either. The original fear >>> that lazy evaluation of filtering/mapping/reducing/etc... operations on >>> collections would feel unnatural to casual programmer, because collections >>> library is currently not using any form of lazy evaluation is, I think, at >>> least partialy unfounded. >>> >>> Lazy evaluation of operations on collection can be described as having two >>> subtle semantic properties: >>> >>> 1. The evaluation of predicates, mappers, reducers, etc. happens at the >>> latest possible moment, when the resulting data is requested (iterated over, >>> collected into a propper collection, etc...) >>> >>> 2. The original data that is the source for the operations is stored in the >>> source collection (the resulting Iterable is not detatched from original >>> data - it is a transformed view over source collection). So modifying source >>> collection before or in the middle of iteration over the result has a >>> consequence on the result. >>> >>> The 2nd property is already known to users of collections library >>> (Map.keySet(), Map.values(), ...) and therefore, if propperly documented, >>> can not present any additional confusion. >>> >>> The 1st property is something new that everyone will have to learn since >>> more and more APIs can be expected to exhibit this behaviour after lambdas >>> are introduced to Java. Programmers will have to learn about pure functions >>> and why they are their friends... >>> >>> I'm now a supporter of lazy java.lang.Iterable (and by inheritance also >>> java.util.Collection). Overall it represents simpler and more consistent API >>> with no need for additional Stream type. It does not exhibit problems that >>> eager evaluation does: >>> >>> - what should the eager result type be and what implementation should be >>> choosen (ArrayList/HashSet/TreeSet) >>> - inherent sub-optimabillity (think of how easy it is to write: s = s + >>> "xxx"; s = s + "..."; ...instead of using StringBuilder) >>> >>> Peter >>> >>>> R?mi >>>> >>>> >>>> >>> > > From spullara at gmail.com Mon Mar 14 07:48:07 2011 From: spullara at gmail.com (Sam Pullara) Date: Mon, 14 Mar 2011 07:48:07 -0700 Subject: Design for collections upgrades In-Reply-To: <4D7E27D2.5000208@univ-mlv.fr> References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> <4D7E21FB.2090609@univ-mlv.fr> <4676177670040766096@unknownmsgid> <4D7E27D2.5000208@univ-mlv.fr> Message-ID: <-6186544827744280187@unknownmsgid> The List is an Iterable. Sent from my iPhone On Mar 14, 2011, at 7:38 AM, R?mi Forax wrote: > On 03/14/2011 03:33 PM, Sam Pullara wrote: >> If we use Iterable for stream it would be the same number of objects >> since the for loop is making the same object. The only real difference >> is the lambda. >> >> Sent from my iPhone > > I don't follow you on this. > The for loop create an iterator not an iterable. > > R???mi > >> On Mar 14, 2011, at 7:30 AM, R???mi Forax wrote: >> >>> The corresponding code is: >>> return people.map(#{ p -> p.getAddress() }).to(new ArrayList<>()); >>> >>> It create one supplementary object (the stream) compared to the code you >>> provide >>> and should be a little slower because currently the lambda code is not >>> inlined >>> into the code of map(). >>> But if the list is not big<10 000 elements you should not notice it. >>> >>> R???mi >>> >>> On 03/14/2011 02:25 PM, Craig P. Motlin wrote: >>>> The problem is that the result of calling filter or transform on a lazy >>>> collection is another lazy collection, which makes them very hard to adopt. >>>> There's a lot of code out there that's already doing transformations like >>>> this: >>>> >>>> public List
doTransform(List people) >>>> { >>>> List
result = new ArrayList
(); >>>> for (Person person : people) >>>> { >>>> result.add(person.getAddress()); >>>> } >>>> return result; >>>> } >>>> >>>> Since it's public, it might be really hard to change the return type to a >>>> lazy collection. The same argument applies for fields. In order to use a >>>> lambda here, the code would become transform().asList(), which will be >>>> slower than the original code. And if it's slower, it will hurt adoption. >>>> >>>> There is one problem with covariant return types at compile time. It's easy >>>> for filter(), it can always be covariant. It's a little different for >>>> transform(). When you transform an ArrayList, you should get back another >>>> ArrayList by default. Sometimes people will want to collapse duplicates but >>>> you shouldn't have to create an ArrayList just to create a HashSet right >>>> afterwards. So it makes sense to have a second form of transform() and >>>> filter() that take a second argument, a mutable collection to dump their >>>> output into. HashSet.transform() should also return a HashSet by default. >>>> For TreeSet, that's impossible though. If you're starting with a >>>> TreeSet then it was constructed with some Comparator. You >>>> can't return SortedSet
from transform() because there's no >>>> Comparator
. It actually makes sense for SortedSet.transform() to >>>> return a List. Since SortedSet extends Set, there are two difficult choices. >>>> >>>> - Have Set and SortedSet both return HashSet >>>> - Have Set return Set and SortedSet return List but the static type they >>>> return is just Collection >>>> >>>> >>>> On Mon, Mar 14, 2011 at 4:07 AM, Peter Levartwrote: >>>> >>>>> On 03/10/11, R???mi Forax wrote: >>>>>> Le 10/03/2011 13:10, Peter Levart a ???crit : >>>>>>> Let Iterable by default (via defender methods) be lazy but let >>>>> Collection (also via defender methods) override the same methods an make >>>>> them eager. Also privide two methods to switch between eager and lazy on the >>>>> Iterable itself (and override in Collection and subtypes). >>>>>> If Collection.filter overrides Iterable.filter, they should have the >>>>>> same semantics. >>>>>> And as I already say, how to implement toEager() ? >>>>> Now after more discussion on the list, I'm not supporting my suggestion any >>>>> further. But I'm not keen on a new "Stream" type either. The original fear >>>>> that lazy evaluation of filtering/mapping/reducing/etc... operations on >>>>> collections would feel unnatural to casual programmer, because collections >>>>> library is currently not using any form of lazy evaluation is, I think, at >>>>> least partialy unfounded. >>>>> >>>>> Lazy evaluation of operations on collection can be described as having two >>>>> subtle semantic properties: >>>>> >>>>> 1. The evaluation of predicates, mappers, reducers, etc. happens at the >>>>> latest possible moment, when the resulting data is requested (iterated over, >>>>> collected into a propper collection, etc...) >>>>> >>>>> 2. The original data that is the source for the operations is stored in the >>>>> source collection (the resulting Iterable is not detatched from original >>>>> data - it is a transformed view over source collection). So modifying source >>>>> collection before or in the middle of iteration over the result has a >>>>> consequence on the result. >>>>> >>>>> The 2nd property is already known to users of collections library >>>>> (Map.keySet(), Map.values(), ...) and therefore, if propperly documented, >>>>> can not present any additional confusion. >>>>> >>>>> The 1st property is something new that everyone will have to learn since >>>>> more and more APIs can be expected to exhibit this behaviour after lambdas >>>>> are introduced to Java. Programmers will have to learn about pure functions >>>>> and why they are their friends... >>>>> >>>>> I'm now a supporter of lazy java.lang.Iterable (and by inheritance also >>>>> java.util.Collection). Overall it represents simpler and more consistent API >>>>> with no need for additional Stream type. It does not exhibit problems that >>>>> eager evaluation does: >>>>> >>>>> - what should the eager result type be and what implementation should be >>>>> choosen (ArrayList/HashSet/TreeSet) >>>>> - inherent sub-optimabillity (think of how easy it is to write: s = s + >>>>> "xxx"; s = s + "..."; ...instead of using StringBuilder) >>>>> >>>>> Peter >>>>> >>>>>> R???mi >>>>>> >>>>>> >>>>>> >>> > From spullara at gmail.com Mon Mar 14 08:06:53 2011 From: spullara at gmail.com (Sam Pullara) Date: Mon, 14 Mar 2011 08:06:53 -0700 Subject: Design for collections upgrades In-Reply-To: <4D7E27D2.5000208@univ-mlv.fr> References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> <4D7E21FB.2090609@univ-mlv.fr> <4676177670040766096@unknownmsgid> <4D7E27D2.5000208@univ-mlv.fr> Message-ID: <-1317115006247475939@unknownmsgid> Ah, the intermediate Iterable. Too early :) Sent from my iPhone On Mar 14, 2011, at 7:38 AM, "R?mi Forax" wrote: > On 03/14/2011 03:33 PM, Sam Pullara wrote: >> If we use Iterable for stream it would be the same number of objects >> since the for loop is making the same object. The only real difference >> is the lambda. >> >> Sent from my iPhone > > I don't follow you on this. > The for loop create an iterator not an iterable. > > R???mi > >> On Mar 14, 2011, at 7:30 AM, R???mi Forax wrote: >> >>> The corresponding code is: >>> return people.map(#{ p -> p.getAddress() }).to(new ArrayList<>()); >>> >>> It create one supplementary object (the stream) compared to the code you >>> provide >>> and should be a little slower because currently the lambda code is not >>> inlined >>> into the code of map(). >>> But if the list is not big<10 000 elements you should not notice it. >>> >>> R???mi >>> >>> On 03/14/2011 02:25 PM, Craig P. Motlin wrote: >>>> The problem is that the result of calling filter or transform on a lazy >>>> collection is another lazy collection, which makes them very hard to adopt. >>>> There's a lot of code out there that's already doing transformations like >>>> this: >>>> >>>> public List
doTransform(List people) >>>> { >>>> List
result = new ArrayList
(); >>>> for (Person person : people) >>>> { >>>> result.add(person.getAddress()); >>>> } >>>> return result; >>>> } >>>> >>>> Since it's public, it might be really hard to change the return type to a >>>> lazy collection. The same argument applies for fields. In order to use a >>>> lambda here, the code would become transform().asList(), which will be >>>> slower than the original code. And if it's slower, it will hurt adoption. >>>> >>>> There is one problem with covariant return types at compile time. It's easy >>>> for filter(), it can always be covariant. It's a little different for >>>> transform(). When you transform an ArrayList, you should get back another >>>> ArrayList by default. Sometimes people will want to collapse duplicates but >>>> you shouldn't have to create an ArrayList just to create a HashSet right >>>> afterwards. So it makes sense to have a second form of transform() and >>>> filter() that take a second argument, a mutable collection to dump their >>>> output into. HashSet.transform() should also return a HashSet by default. >>>> For TreeSet, that's impossible though. If you're starting with a >>>> TreeSet then it was constructed with some Comparator. You >>>> can't return SortedSet
from transform() because there's no >>>> Comparator
. It actually makes sense for SortedSet.transform() to >>>> return a List. Since SortedSet extends Set, there are two difficult choices. >>>> >>>> - Have Set and SortedSet both return HashSet >>>> - Have Set return Set and SortedSet return List but the static type they >>>> return is just Collection >>>> >>>> >>>> On Mon, Mar 14, 2011 at 4:07 AM, Peter Levartwrote: >>>> >>>>> On 03/10/11, R???mi Forax wrote: >>>>>> Le 10/03/2011 13:10, Peter Levart a ???crit : >>>>>>> Let Iterable by default (via defender methods) be lazy but let >>>>> Collection (also via defender methods) override the same methods an make >>>>> them eager. Also privide two methods to switch between eager and lazy on the >>>>> Iterable itself (and override in Collection and subtypes). >>>>>> If Collection.filter overrides Iterable.filter, they should have the >>>>>> same semantics. >>>>>> And as I already say, how to implement toEager() ? >>>>> Now after more discussion on the list, I'm not supporting my suggestion any >>>>> further. But I'm not keen on a new "Stream" type either. The original fear >>>>> that lazy evaluation of filtering/mapping/reducing/etc... operations on >>>>> collections would feel unnatural to casual programmer, because collections >>>>> library is currently not using any form of lazy evaluation is, I think, at >>>>> least partialy unfounded. >>>>> >>>>> Lazy evaluation of operations on collection can be described as having two >>>>> subtle semantic properties: >>>>> >>>>> 1. The evaluation of predicates, mappers, reducers, etc. happens at the >>>>> latest possible moment, when the resulting data is requested (iterated over, >>>>> collected into a propper collection, etc...) >>>>> >>>>> 2. The original data that is the source for the operations is stored in the >>>>> source collection (the resulting Iterable is not detatched from original >>>>> data - it is a transformed view over source collection). So modifying source >>>>> collection before or in the middle of iteration over the result has a >>>>> consequence on the result. >>>>> >>>>> The 2nd property is already known to users of collections library >>>>> (Map.keySet(), Map.values(), ...) and therefore, if propperly documented, >>>>> can not present any additional confusion. >>>>> >>>>> The 1st property is something new that everyone will have to learn since >>>>> more and more APIs can be expected to exhibit this behaviour after lambdas >>>>> are introduced to Java. Programmers will have to learn about pure functions >>>>> and why they are their friends... >>>>> >>>>> I'm now a supporter of lazy java.lang.Iterable (and by inheritance also >>>>> java.util.Collection). Overall it represents simpler and more consistent API >>>>> with no need for additional Stream type. It does not exhibit problems that >>>>> eager evaluation does: >>>>> >>>>> - what should the eager result type be and what implementation should be >>>>> choosen (ArrayList/HashSet/TreeSet) >>>>> - inherent sub-optimabillity (think of how easy it is to write: s = s + >>>>> "xxx"; s = s + "..."; ...instead of using StringBuilder) >>>>> >>>>> Peter >>>>> >>>>>> R???mi >>>>>> >>>>>> >>>>>> >>> > From motlin at gmail.com Mon Mar 14 08:41:22 2011 From: motlin at gmail.com (Craig P. Motlin) Date: Mon, 14 Mar 2011 11:41:22 -0400 Subject: Design for collections upgrades In-Reply-To: <4D7E242C.1090004@univ-mlv.fr> References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> <4D7E242C.1090004@univ-mlv.fr> Message-ID: In the Scalable implementation, both println statements print the same thing. Yes that's confusing, but its very similar to mutating a collection while working with lazy evaluation. On Mar 14, 2011 10:39 AM, "R?mi Forax" wrote: > On 03/14/2011 02:30 PM, Craig P. Motlin wrote: >> There are two forms of lazy evaluation and I see people using the same term >> (Stream) to refer to both. In Scala they are called view and stream and I >> was confused about the difference so I asked on Stack Overflow. Basically >> the difference is: >> In a view elements are recomputed each time they are accessed. In a stream >> elements are retained as they are evaluated. >> >> I think that Java collections ought to support both, which is another reason >> I think that eager ought to be the default. See the full explanation here: >> http://stackoverflow.com/questions/2282754/what-is-the-difference-between-a-view-and-a-stream > > Interresting. > But memoization is hard to provide when your original collection is mutable: > > What does this code print ? > > LinkedList list = new LinkedList<>(); > Collections.addAll(list, 1, 2, 3, 4, 5); > List list2 = list.asScalaStreamPlease(); > System.out.println(list2.join(" ")); // the whole list is now memoized > > list.remove(0); // wink wink > System.out.println(list2.join(" ")); > > R?mi > > From forax at univ-mlv.fr Mon Mar 14 08:41:52 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 14 Mar 2011 16:41:52 +0100 Subject: Design for collections upgrades In-Reply-To: References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> <4D7E242C.1090004@univ-mlv.fr> Message-ID: <4D7E3740.7090906@univ-mlv.fr> On 03/14/2011 04:41 PM, Craig P. Motlin wrote: > > In the Scalable implementation, both println statements print the same > thing. Yes that's confusing, but its very similar to mutating a > collection while working with lazy evaluation. > No, in Java you will get a fail fast ConcurrentModificationException if you mutate during a lazy evaluation. R?mi > On Mar 14, 2011 10:39 AM, "R?mi Forax" > wrote: > > On 03/14/2011 02:30 PM, Craig P. Motlin wrote: > >> There are two forms of lazy evaluation and I see people using the > same term > >> (Stream) to refer to both. In Scala they are called view and stream > and I > >> was confused about the difference so I asked on Stack Overflow. > Basically > >> the difference is: > >> In a view elements are recomputed each time they are accessed. In a > stream > >> elements are retained as they are evaluated. > >> > >> I think that Java collections ought to support both, which is > another reason > >> I think that eager ought to be the default. See the full > explanation here: > >> > http://stackoverflow.com/questions/2282754/what-is-the-difference-between-a-view-and-a-stream > > > > Interresting. > > But memoization is hard to provide when your original collection is > mutable: > > > > What does this code print ? > > > > LinkedList list = new LinkedList<>(); > > Collections.addAll(list, 1, 2, 3, 4, 5); > > List list2 = list.asScalaStreamPlease(); > > System.out.println(list2.join(" ")); // the whole list is now memoized > > > > list.remove(0); // wink wink > > System.out.println(list2.join(" ")); > > > > R?mi > > > > From motlin at gmail.com Mon Mar 14 08:51:05 2011 From: motlin at gmail.com (Craig P. Motlin) Date: Mon, 14 Mar 2011 11:51:05 -0400 Subject: Design for collections upgrades In-Reply-To: <4D7E3740.7090906@univ-mlv.fr> References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> <4D7E242C.1090004@univ-mlv.fr> <4D7E3740.7090906@univ-mlv.fr> Message-ID: Sorry I was talking about Scala. My phone changed it to "scalable" On Mar 14, 2011 11:44 AM, "R?mi Forax" wrote: > On 03/14/2011 04:41 PM, Craig P. Motlin wrote: >> >> In the Scalable implementation, both println statements print the same >> thing. Yes that's confusing, but its very similar to mutating a >> collection while working with lazy evaluation. >> > > No, in Java you will get a fail fast ConcurrentModificationException > if you mutate during a lazy evaluation. > > R?mi > >> On Mar 14, 2011 10:39 AM, "R?mi Forax" > > wrote: >> > On 03/14/2011 02:30 PM, Craig P. Motlin wrote: >> >> There are two forms of lazy evaluation and I see people using the >> same term >> >> (Stream) to refer to both. In Scala they are called view and stream >> and I >> >> was confused about the difference so I asked on Stack Overflow. >> Basically >> >> the difference is: >> >> In a view elements are recomputed each time they are accessed. In a >> stream >> >> elements are retained as they are evaluated. >> >> >> >> I think that Java collections ought to support both, which is >> another reason >> >> I think that eager ought to be the default. See the full >> explanation here: >> >> >> http://stackoverflow.com/questions/2282754/what-is-the-difference-between-a-view-and-a-stream >> > >> > Interresting. >> > But memoization is hard to provide when your original collection is >> mutable: >> > >> > What does this code print ? >> > >> > LinkedList list = new LinkedList<>(); >> > Collections.addAll(list, 1, 2, 3, 4, 5); >> > List list2 = list.asScalaStreamPlease(); >> > System.out.println(list2.join(" ")); // the whole list is now memoized >> > >> > list.remove(0); // wink wink >> > System.out.println(list2.join(" ")); >> > >> > R?mi >> > >> > > From forax at univ-mlv.fr Mon Mar 14 08:59:18 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 14 Mar 2011 16:59:18 +0100 Subject: Design for collections upgrades In-Reply-To: <4D7E3279.50102@univ-mlv.fr> References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> <4D7E21FB.2090609@univ-mlv.fr> <4676177670040766096@unknownmsgid> <4D7E27D2.5000208@univ-mlv.fr> <-1317115006247475939@unknownmsgid> <4D7E3279.50102@univ-mlv.fr> Message-ID: <4D7E3B56.2050006@univ-mlv.fr> On 03/14/2011 04:21 PM, R?mi Forax wrote: > On 03/14/2011 04:06 PM, Sam Pullara wrote: >> Ah, the intermediate Iterable. Too early :) >> >> Sent from my iPhone > Yes ! > I've just thought that it's a good candidate for escape analysis :) > > R?mi > I've found a trick to be as fast the foreach version if there is only one filter, one mapper or a combination of one filter followed by one mapper. Basically, in the intermediary iterable, you can override reduce() and to() and write a version with a foreach :) R?mi From john at milsson.nu Mon Mar 14 09:07:25 2011 From: john at milsson.nu (John Nilsson) Date: Mon, 14 Mar 2011 17:07:25 +0100 Subject: Design for collections upgrades In-Reply-To: <4D7E3B56.2050006@univ-mlv.fr> References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> <4D7E21FB.2090609@univ-mlv.fr> <4676177670040766096@unknownmsgid> <4D7E27D2.5000208@univ-mlv.fr> <-1317115006247475939@unknownmsgid> <4D7E3279.50102@univ-mlv.fr> <4D7E3B56.2050006@univ-mlv.fr> Message-ID: Isn't that what they call Deforestation[1]? BR, John [1] http://en.wikipedia.org/wiki/Deforestation_(computer_science) On Mon, Mar 14, 2011 at 4:59 PM, R?mi Forax wrote: > On 03/14/2011 04:21 PM, R?mi Forax wrote: >> On 03/14/2011 04:06 PM, Sam Pullara wrote: >>> Ah, the intermediate Iterable. Too early :) >>> >>> Sent from my iPhone >> Yes ! >> I've just thought that it's a good candidate for escape analysis :) >> >> R?mi >> > > I've found a trick to be as fast the foreach version if > there is only one filter, one mapper or a combination of > one filter followed by one mapper. > > Basically, in the intermediary iterable, you can override > reduce() and to() and write a version with a foreach :) > > R?mi > > > From forax at univ-mlv.fr Mon Mar 14 09:15:25 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 14 Mar 2011 17:15:25 +0100 Subject: Design for collections upgrades In-Reply-To: References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> <4D7E21FB.2090609@univ-mlv.fr> <4676177670040766096@unknownmsgid> <4D7E27D2.5000208@univ-mlv.fr> <-1317115006247475939@unknownmsgid> <4D7E3279.50102@univ-mlv.fr> <4D7E3B56.2050006@univ-mlv.fr> Message-ID: <4D7E3F1D.9050803@univ-mlv.fr> No deforestation is when you do remove intermediary step between transformations. by example reverse(reverse) => identity or in Java, map(#{ s - > s.toUpperCase() }).map(#{ s -> s.length() }) can be transformed to map(#{ s -> s.toUpperCase().length() }) and then to map(#{ s -> s.length() } It remember my master thesis on attributed grammars which is an intermediary representation that can be used to do this kind of transformation. R?mi On 03/14/2011 05:07 PM, John Nilsson wrote: > Isn't that what they call Deforestation[1]? > > BR, > John > > [1] http://en.wikipedia.org/wiki/Deforestation_(computer_science) > > On Mon, Mar 14, 2011 at 4:59 PM, R?mi Forax wrote: >> On 03/14/2011 04:21 PM, R?mi Forax wrote: >>> On 03/14/2011 04:06 PM, Sam Pullara wrote: >>>> Ah, the intermediate Iterable. Too early :) >>>> >>>> Sent from my iPhone >>> Yes ! >>> I've just thought that it's a good candidate for escape analysis :) >>> >>> R?mi >>> >> I've found a trick to be as fast the foreach version if >> there is only one filter, one mapper or a combination of >> one filter followed by one mapper. >> >> Basically, in the intermediary iterable, you can override >> reduce() and to() and write a version with a foreach :) >> >> R?mi >> >> >> From motlin at gmail.com Mon Mar 14 18:20:16 2011 From: motlin at gmail.com (Craig P. Motlin) Date: Mon, 14 Mar 2011 21:20:16 -0400 Subject: Design for collections upgrades In-Reply-To: <4D7E3740.7090906@univ-mlv.fr> References: <201103101310.38531.peter.levart@marand.si> <4D78D96F.4070907@univ-mlv.fr> <201103140907.52816.peter.levart@marand.si> <4D7E242C.1090004@univ-mlv.fr> <4D7E3740.7090906@univ-mlv.fr> Message-ID: Here's what happens in Scala if you mutate after iterating through the Stream. scala> import scala.collection.mutable._ scala> val buffer = new ArrayBuffer[Int] scala> buffer ++= List(1, 2, 3) scala> val stream = buffer.toStream stream: scala.collection.immutable.Stream[Int] = Stream(1, ?) scala> stream.toString res2: String = Stream(1, ?) scala> stream.foreach(println) 1 2 3 scala> stream.toString res4: String = Stream(1, 2, 3) scala> buffer.remove(0) res5: Int = 1 scala> stream.toString res6: String = Stream(1, 2, 3) And here's what happens if you mutate before the Stream has a chance to fully memoize. scala> val stream2 = buffer.toStream stream2: scala.collection.immutable.Stream[Int] = Stream(2, ?) scala> buffer.remove(0) res7: Int = 2 scala> stream2.toString res8: String = Stream(2, ?) scala> stream2.foreach(println) 2 java.lang.IndexOutOfBoundsException: 1 at scala.collection.mutable.ResizableArray$class.apply(ResizableArray.scala:45) at scala.collection.mutable.ArrayBuffer.apply(ArrayBuffer.scala:43) at scala.collection.IndexedSeqLike$Elements.next(IndexedSeqLike.scala:59) at scala.collection.Iterator$class.toStream(Iterator.scala:1011) at scala.collection.IndexedSeqLike$Elements.toStream(IndexedSeqLike.scala:52) at scala.collection.Iterator$$anonfun$toStream$1.apply(Iterator.scala:1011) at scala.collection.Iterator$$anonfun$toStream$1.apply(Iterator.scala:1011) at scala.collection.immutable.Stream$Cons.tail(Stream.scala:565) at scala.collection.immutable.Stream$Cons.tail(Stream.scala:557) at scala.collection.immutable.Stream.foreach(Stream.scala:261) at .(:11) at . wrote: > On 03/14/2011 04:41 PM, Craig P. Motlin wrote: > > In the Scalable implementation, both println statements print the same > thing. Yes that's confusing, but its very similar to mutating a collection > while working with lazy evaluation. > > > No, in Java you will get a fail fast ConcurrentModificationException > if you mutate during a lazy evaluation. > > R?mi > > > On Mar 14, 2011 10:39 AM, "R?mi Forax" wrote: > > On 03/14/2011 02:30 PM, Craig P. Motlin wrote: > >> There are two forms of lazy evaluation and I see people using the same > term > >> (Stream) to refer to both. In Scala they are called view and stream and > I > >> was confused about the difference so I asked on Stack Overflow. > Basically > >> the difference is: > >> In a view elements are recomputed each time they are accessed. In a > stream > >> elements are retained as they are evaluated. > >> > >> I think that Java collections ought to support both, which is another > reason > >> I think that eager ought to be the default. See the full explanation > here: > >> > http://stackoverflow.com/questions/2282754/what-is-the-difference-between-a-view-and-a-stream > > > > Interresting. > > But memoization is hard to provide when your original collection is > mutable: > > > > What does this code print ? > > > > LinkedList list = new LinkedList<>(); > > Collections.addAll(list, 1, 2, 3, 4, 5); > > List list2 = list.asScalaStreamPlease(); > > System.out.println(list2.join(" ")); // the whole list is now memoized > > > > list.remove(0); // wink wink > > System.out.println(list2.join(" ")); > > > > R?mi > > > > > > > From forax at univ-mlv.fr Tue Mar 15 08:34:59 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 15 Mar 2011 16:34:59 +0100 Subject: Cyclic what ? Message-ID: <4D7F8723.6040601@univ-mlv.fr> Maurizio, This snippet emit a warning. I don't understand why it doesn't just compile and why it emit a warning and not an error. public interface Mapper { public U map(T t); } public static Mapper compose(Mapper mapper1, Mapper mapper2) { return #{ t -> mapper2.map(mapper1.map(t)) }; } warning: thrown types cannot be inferred from lambda body because of cyclic inference return #{ t -> mapper2.map(mapper1.map(t)) }; ^ explicit type required for the following parameter: t R?mi From forax at univ-mlv.fr Tue Mar 15 08:41:32 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 15 Mar 2011 16:41:32 +0100 Subject: I feel rejected :) Message-ID: <4D7F88AC.7020603@univ-mlv.fr> And this one crash the compiler: public interface Folder { public T fold(T a, T b); } public static Folder max() { return #{ a, b -> (((Comparable)a).compareTo(b)<0)? b: a }; } It doesn't like the cast in the lambda. R?mi From maurizio.cimadamore at oracle.com Tue Mar 15 08:55:14 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 15 Mar 2011 15:55:14 +0000 Subject: I feel rejected :) In-Reply-To: <4D7F88AC.7020603@univ-mlv.fr> References: <4D7F88AC.7020603@univ-mlv.fr> Message-ID: <4D7F8BE2.4060803@oracle.com> On 15/03/11 15:41, R?mi Forax wrote: > public interface Folder { > public T fold(T a, T b); > } > > public static Folder max() { > return #{ a, b -> (((Comparable)a).compareTo(b)<0)? b: a }; > } Both problems in this and in your earlier example are caused by corner cases in the type-inference scheme implemented in the lambda prototype. The implemented scheme is provisional - and we are working to gradually replace it with an algorithm that matches the latest version of the lambda spec that is being discussed as part of JSR 335. Thanks Maurizio From maurizio.cimadamore at oracle.com Tue Mar 15 10:22:13 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 15 Mar 2011 17:22:13 +0000 Subject: hg: lambda/lambda/langtools: Bug fix: attribution of lambda expression throw AssertionError Message-ID: <20110315172217.8F80847184@hg.openjdk.java.net> Changeset: cb9074345db0 Author: mcimadamore Date: 2011-03-15 17:21 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/cb9074345db0 Bug fix: attribution of lambda expression throw AssertionError Attribution of lambda expression crashes if lambda contains a cast involving lambda parameter w/o explicit type. ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/TargetType18.java From brian.goetz at oracle.com Tue Mar 15 12:15:10 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 15 Mar 2011 19:15:10 +0000 Subject: hg: lambda/collections/langtools: 2 new changesets Message-ID: <20110315191521.420F54718C@hg.openjdk.java.net> Changeset: cb9074345db0 Author: mcimadamore Date: 2011-03-15 17:21 +0000 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/cb9074345db0 Bug fix: attribution of lambda expression throw AssertionError Attribution of lambda expression crashes if lambda contains a cast involving lambda parameter w/o explicit type. ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/TargetType18.java Changeset: e4d6738ea2da Author: briangoetz Date: 2011-03-15 15:12 -0400 URL: http://hg.openjdk.java.net/lambda/collections/langtools/rev/e4d6738ea2da Merge From neal at gafter.com Tue Mar 15 13:32:06 2011 From: neal at gafter.com (Neal Gafter) Date: Tue, 15 Mar 2011 13:32:06 -0700 Subject: I feel rejected :) In-Reply-To: <4D7F88AC.7020603@univ-mlv.fr> References: <4D7F88AC.7020603@univ-mlv.fr> Message-ID: R?mi- I don't like casts either. Did you mean * public interface Folder { public T fold(T a, T b); } public static > Folder max() { return #{ a, b -> a.compareTo(b)<0 ? b : a }; }* Cheers, Neal On Tue, Mar 15, 2011 at 8:41 AM, R?mi Forax wrote: > And this one crash the compiler: > > public interface Folder { > public T fold(T a, T b); > } > > public static Folder max() { > return #{ a, b -> (((Comparable)a).compareTo(b)<0)? b: a }; > } > > It doesn't like the cast in the lambda. > > R?mi > > > From les at lesstroud.com Tue Mar 15 13:46:34 2011 From: les at lesstroud.com (Les Stroud) Date: Tue, 15 Mar 2011 16:46:34 -0400 Subject: I feel rejected :) In-Reply-To: References: <4D7F88AC.7020603@univ-mlv.fr> Message-ID: <7A57264A-E747-4011-AB9A-8CDF36E14D61@lesstroud.com> Not to butt in, but I?m not sure which one is 'less pretty', the xml version or the lisp version (<<<< vs ((( ) :) LES On Mar 15, 2011, at 4:32 PM, Neal Gafter wrote: > R?mi- > > I don't like casts either. Did you mean > * > public interface Folder { > public T fold(T a, T b); > } > > public static > Folder max() { > return #{ a, b -> a.compareTo(b)<0 ? b : a }; > }* > > Cheers, > Neal > > On Tue, Mar 15, 2011 at 8:41 AM, R?mi Forax wrote: > >> And this one crash the compiler: >> >> public interface Folder { >> public T fold(T a, T b); >> } >> >> public static Folder max() { >> return #{ a, b -> (((Comparable)a).compareTo(b)<0)? b: a }; >> } >> >> It doesn't like the cast in the lambda. >> >> R?mi >> >> >> > -- Les Stroud Developer, Architect, Creative Thinker web: lesstroud.com email: les at lesstroud.com linked in | twitter | facebook From forax at univ-mlv.fr Tue Mar 15 15:03:03 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 15 Mar 2011 23:03:03 +0100 Subject: I feel rejected :) In-Reply-To: References: <4D7F88AC.7020603@univ-mlv.fr> Message-ID: <4D7FE217.2060807@univ-mlv.fr> On 03/15/2011 09:32 PM, Neal Gafter wrote: > R?mi- > > I don't like casts either. Did you mean > * > public interface Folder { > public T fold(T a, T b); > } > > public static > Folder max() { > return #{ a, b -> a.compareTo(b)<0 ? b : a }; > }* > > Cheers, > Neal Yes, but I want a runtime exception here, my test does a reduce on an array of objects. cheers, R?mi > > On Tue, Mar 15, 2011 at 8:41 AM, R?mi Forax > wrote: > > And this one crash the compiler: > > public interface Folder { > public T fold(T a, T b); > } > > public static Folder max() { > return #{ a, b -> (((Comparable)a).compareTo(b)<0)? b: a }; > } > > It doesn't like the cast in the lambda. > > R?mi > > > From daniel.smith at oracle.com Tue Mar 15 16:34:53 2011 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 15 Mar 2011 16:34:53 -0700 Subject: I feel rejected :) In-Reply-To: <7A57264A-E747-4011-AB9A-8CDF36E14D61@lesstroud.com> References: <4D7F88AC.7020603@univ-mlv.fr> <7A57264A-E747-4011-AB9A-8CDF36E14D61@lesstroud.com> Message-ID: <228ABDDC-28E5-4A7A-9E61-66F785DB69F9@oracle.com> From Gilad's 2004 generics tutorial [1]: > Now, you might think that all we?ve accomplished is to move the clutter around. Instead of a cast to Integer on line 3, we have Integer as a type parameter on line 1?. However, there is a very big difference here. The compiler can now check the type correctness of the program at compile-time. When we say that myIntList is declared with type List, this tells us something about the variable myIntList, which holds true wherever and whenever it is used, and the compiler will guarantee it. In contrast, the cast tells us something the programmer thinks is true at a single point in the code. The refactoring, unfortunately, doesn't produce something particularly more pretty. But it's a lot more robust. ?Dan [1] http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf On Mar 15, 2011, at 1:46 PM, Les Stroud wrote: > Not to butt in, but I?m not sure which one is 'less pretty', the xml version or the lisp version (<<<< vs ((( ) :) > > LES > > On Mar 15, 2011, at 4:32 PM, Neal Gafter wrote: > >> R?mi- >> >> I don't like casts either. Did you mean >> * >> public interface Folder { >> public T fold(T a, T b); >> } >> >> public static > Folder max() { >> return #{ a, b -> a.compareTo(b)<0 ? b : a }; >> }* >> >> Cheers, >> Neal >> >> On Tue, Mar 15, 2011 at 8:41 AM, R?mi Forax wrote: >> >>> And this one crash the compiler: >>> >>> public interface Folder { >>> public T fold(T a, T b); >>> } >>> >>> public static Folder max() { >>> return #{ a, b -> (((Comparable)a).compareTo(b)<0)? b: a }; >>> } >>> >>> It doesn't like the cast in the lambda. >>> >>> R?mi >>> >>> >>> >> > > > -- > Les Stroud Developer, Architect, Creative Thinker > web: lesstroud.com email: les at lesstroud.com linked in | twitter | facebook > > > > > From neal at gafter.com Fri Mar 18 22:51:00 2011 From: neal at gafter.com (Neal Gafter) Date: Fri, 18 Mar 2011 22:51:00 -0700 Subject: Expert group mailing list Message-ID: We've been told that expert groups such as the JSR for lambdas would hold their deliberations in a publicly-readable forum. How do I subscribe? Where do I find the archives of the discussion? From forax at univ-mlv.fr Sat Mar 19 04:25:41 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 19 Mar 2011 12:25:41 +0100 Subject: Expert group mailing list In-Reply-To: References: Message-ID: <4D8492B5.8060005@univ-mlv.fr> On 03/19/2011 06:51 AM, Neal Gafter wrote: > We've been told that expert groups such as the JSR for lambdas would hold > their deliberations in a publicly-readable forum. > > How do I subscribe? Where do I find the archives of the discussion? > This is not an answer to all your questions but we have planned to post a draft of spec as soon as possible here. But we aren't ready yet. R?mi From neal at gafter.com Sat Mar 19 09:36:34 2011 From: neal at gafter.com (Neal Gafter) Date: Sat, 19 Mar 2011 09:36:34 -0700 Subject: Expert group mailing list In-Reply-To: <4D8492B5.8060005@univ-mlv.fr> References: <4D8492B5.8060005@univ-mlv.fr> Message-ID: I expect a perusal of the mailing list archives would help me understand the sense of the expert group on their open issues. On Sat, Mar 19, 2011 at 4:25 AM, R?mi Forax wrote: > On 03/19/2011 06:51 AM, Neal Gafter wrote: > > We've been told that expert groups such as the JSR for lambdas would hold > > their deliberations in a publicly-readable forum. > > > > How do I subscribe? Where do I find the archives of the discussion? > > > > This is not an answer to all your questions but > we have planned to post a draft of spec as soon as possible here. > But we aren't ready yet. > > R?mi > > > From robert.field at oracle.com Mon Mar 21 20:03:16 2011 From: robert.field at oracle.com (robert.field at oracle.com) Date: Tue, 22 Mar 2011 03:03:16 +0000 Subject: hg: lambda/defender-prototype: add BridgeTest (currently failing; change MultipleInheritanceTest to be valid under current spec Message-ID: <20110322030316.F19DB47363@hg.openjdk.java.net> Changeset: 9a097a661267 Author: Robert Field Date: 2011-03-21 20:03 -0700 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/9a097a661267 add BridgeTest (currently failing; change MultipleInheritanceTest to be valid under current spec ! src/jsr335/agent/WeaveClassAdapter.java + test/jsr335/agent/junit/BridgeTest.java ! test/jsr335/agent/junit/CovariantOverrideTest.java ! test/jsr335/agent/junit/MultipleInheritanceTest.java From robert.field at oracle.com Mon Mar 21 20:10:47 2011 From: robert.field at oracle.com (robert.field at oracle.com) Date: Tue, 22 Mar 2011 03:10:47 +0000 Subject: hg: lambda/defender-prototype: fix an (inappropriate) recursion in spec Message-ID: <20110322031047.C2EB847364@hg.openjdk.java.net> Changeset: 920d9a8e8e90 Author: Robert Field Date: 2011-03-21 20:11 -0700 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/920d9a8e8e90 fix an (inappropriate) recursion in spec ! doc/featherweight-defenders.pdf ! doc/featherweight-defenders.tex From brian.goetz at oracle.com Tue Mar 22 08:56:43 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 22 Mar 2011 15:56:43 +0000 Subject: hg: lambda/defender-prototype: Refactor FD grammar for fewer disjunctions in syntactic preconditions Message-ID: <20110322155643.AA73E4738B@hg.openjdk.java.net> Changeset: 18a7771b6c1b Author: briangoetz Date: 2011-03-22 11:56 -0400 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/18a7771b6c1b Refactor FD grammar for fewer disjunctions in syntactic preconditions ! doc/featherweight-defenders.pdf ! doc/featherweight-defenders.tex From maurizio.cimadamore at oracle.com Fri Mar 25 08:57:52 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 25 Mar 2011 15:57:52 +0000 Subject: hg: lambda/lambda/langtools: Bug fix: SAM conversion and raw types Message-ID: <20110325155759.5BA0E47488@hg.openjdk.java.net> Changeset: 8d77997dfc50 Author: mcimadamore Date: 2011-03-25 15:51 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/8d77997dfc50 Bug fix: SAM conversion and raw types Implement latest changes in lambda spec involving SAM conversion and raw types in argument/return types ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/lambda/LambdaConv16.java From robert.field at oracle.com Fri Mar 25 13:07:37 2011 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 25 Mar 2011 20:07:37 +0000 Subject: hg: lambda/defender-prototype: 2 new changesets Message-ID: <20110325200737.6B4D44749C@hg.openjdk.java.net> Changeset: 33b9f407b69d Author: Robert Field Date: 2011-03-25 13:06 -0700 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/33b9f407b69d Test clean-up (in prep for test changes) ! test/jsr335/agent/junit/BridgeTest.java ! test/jsr335/agent/junit/CovariantOverrideTest.java Changeset: 8a293a405e57 Author: Robert Field Date: 2011-03-25 13:08 -0700 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/8a293a405e57 merge From david.holmes at oracle.com Sun Mar 27 20:08:06 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 28 Mar 2011 03:08:06 +0000 Subject: hg: lambda/collections/jdk: Added explicit support for all 7 primitive types. Message-ID: <20110328030840.AEF7F47521@hg.openjdk.java.net> Changeset: 363cdf746fec Author: dholmes Date: 2011-03-28 13:06 +1000 URL: http://hg.openjdk.java.net/lambda/collections/jdk/rev/363cdf746fec Added explicit support for all 7 primitive types. Float/double support complies with Arrays.sort spec regarding NaNs and -0.0 Test updated to incoporate recent changes to Sorting test, plus enabled tests for all types ! src/share/classes/java/util/concurrent/ForkJoinUtils.java ! test/java/util/concurrent/forkjoin/ParallelSorting.java From maurizio.cimadamore at oracle.com Tue Mar 29 01:52:32 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 29 Mar 2011 08:52:32 +0000 Subject: hg: lambda/lambda/langtools: Update compile-time checks for extension methods. Message-ID: <20110329085239.C4AD647565@hg.openjdk.java.net> Changeset: bb800adbe578 Author: mcimadamore Date: 2011-03-29 09:50 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/bb800adbe578 Update compile-time checks for extension methods. Bring the compiler in sync with the latest version of the formal extension method document at: http://hg.openjdk.java.net/lambda/defender-prototype/raw-file/18a7771b6c1b/doc/featherweight-defenders.pdf ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/defender/Neg01.out ! test/tools/javac/defender/Neg02.out ! test/tools/javac/defender/Neg03.java ! test/tools/javac/defender/Neg03.out + test/tools/javac/defender/Neg04.java + test/tools/javac/defender/Neg04.out + test/tools/javac/defender/Neg05.java + test/tools/javac/defender/Neg05.out ! test/tools/javac/defender/Pos06.java ! test/tools/javac/defender/Pos08.java ! test/tools/javac/defender/Pos09.java ! test/tools/javac/diags/examples.not-yet.txt