From paul.sandoz at oracle.com Sat Dec 1 06:35:22 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Sat, 01 Dec 2012 14:35:22 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121201143615.B6FAB47C6E@hg.openjdk.java.net> Changeset: 509db112d745 Author: psandoz Date: 2012-12-01 15:33 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/509db112d745 - rename {Int}SpinedList to {Int}SpinedBuffer to better reflect the add/replace, no remove, functionality. - move the constants and size calculation methods into a separate class (reduces copying). - keep track of size of spines up to but not including the last spine, which simplifies the size calculation. ! src/share/classes/java/util/stream/op/FlatMapOp.java ! src/share/classes/java/util/stream/op/GroupByOp.java ! src/share/classes/java/util/stream/op/Nodes.java + src/share/classes/java/util/stream/op/SpinedBuffer.java + src/share/classes/java/util/stream/op/SpinedBufferHelper.java - src/share/classes/java/util/stream/op/SpinedList.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java + src/share/classes/java/util/stream/primitive/IntSpinedBuffer.java - src/share/classes/java/util/stream/primitive/IntSpinedList.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/PrimitiveOpsTests.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java Changeset: b8879209d4f6 Author: psandoz Date: 2012-12-01 15:33 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b8879209d4f6 Fixed bug where {Int}SpinedBuffer was reporting one more than the actual natural number of splits. ! src/share/classes/java/util/stream/op/SpinedBuffer.java ! src/share/classes/java/util/stream/primitive/IntSpinedBuffer.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/SpinedBufferTest.java From brian.goetz at oracle.com Sat Dec 1 09:26:22 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sat, 01 Dec 2012 17:26:22 +0000 Subject: hg: lambda/lambda/jdk: Back out StreamSource abstraction; all we need is a Supplier Message-ID: <20121201172633.B343E47C71@hg.openjdk.java.net> Changeset: bd2d3a3e1f8b Author: briangoetz Date: 2012-12-01 12:26 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bd2d3a3e1f8b Back out StreamSource abstraction; all we need is a Supplier ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/lang/CharSequence.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/LinkedHashSet.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedSet.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/StreamSource.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/stream/op/SpinedBuffer.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntSpinedBuffer.java - src/share/classes/java/util/stream/primitive/IntStreamSource.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java From brian.goetz at oracle.com Sat Dec 1 11:32:29 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sat, 01 Dec 2012 19:32:29 +0000 Subject: hg: lambda/lambda/jdk: Additional spliterator tests Message-ID: <20121201193245.67F4047C74@hg.openjdk.java.net> Changeset: d91053d3d68b Author: briangoetz Date: 2012-12-01 14:32 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d91053d3d68b Additional spliterator tests ! test-ng/tests/org/openjdk/tests/java/util/stream/SpliteratorTest.java From brian.goetz at oracle.com Sun Dec 2 15:04:15 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sun, 02 Dec 2012 23:04:15 +0000 Subject: hg: lambda/lambda/jdk: Misc cleanups Message-ID: <20121202230512.0E1D247CA2@hg.openjdk.java.net> Changeset: 6f6b85291247 Author: briangoetz Date: 2012-12-02 18:04 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6f6b85291247 Misc cleanups ! src/share/classes/java/util/stream/StreamShape.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/op/IntermediateOp.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java From david.holmes at oracle.com Sun Dec 2 17:33:51 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 03 Dec 2012 11:33:51 +1000 Subject: Confusing javac error :) In-Reply-To: <50B8A4D1.809@oracle.com> References: <201211300715.qAU7FUOP027278@monge.univ-mlv.fr> <50B88512.5060800@oracle.com> <50B88AAD.2090903@univ-mlv.fr> <50B88E57.2000205@univ-mlv.fr> <50B8A1D8.7050704@gmail.com> <50B8A4D1.809@oracle.com> Message-ID: <50BC017F.1020904@oracle.com> On 30/11/2012 10:21 PM, Maurizio Cimadamore wrote: > Please do not rely on those internal flags. There's a reason why > lambda/default methods are not enabled by default in b65 - first and > foremost because hotspot and JDK changes are not there yet. Let's all > wait for next promotion, or use the lambda repo, shall we? ;-) Thanks for clarifying that. The repo I was playing in was only up to b65. The lambda forest doesn't include any closed repos and so can only do OPENJDK builds - but my build machine is missing things needed to do OPENJDK builds. :( David > Maurizio From david.holmes at oracle.com Sun Dec 2 17:50:46 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 03 Dec 2012 11:50:46 +1000 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50B8FE8A.2030403@oracle.com> References: <50B8FE8A.2030403@oracle.com> Message-ID: <50BC0576.4070202@oracle.com> Hi Akhil, Is it really necessary/desirable to flag all of these as " Suitable for conversion as a method reference to functional interfaces such as ..." ? This style: + * @param a a boolean argument. + * @param b another boolean argument. is at odds with the style used elsewhere for new Functional APIs, and with the style of other methods in these classes. Can we just use "first operand" and "second operand" for all of these? Character.sum does not make sense to me. Who adds together characters? I'm not even sure min and max are worth supporting for Character. I disagree with other suggestions to use the Math functions for float/double. I think all these methods should use the underlying primitive operator regardless of type. Thanks, David ----- On 1/12/2012 4:44 AM, Akhil Arora wrote: > Hi > > Requesting review for some basic functionality related to lambdas - > > Add min, max, sum methods to the primitive wrapper classes - Byte, > Short, Integer, Long, Float, Double and Character so as to be able to > use them as reducers in lambda expressions. Add and, or, xor methods to > Boolean. > > http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201 > > Thanks From paul.sandoz at oracle.com Mon Dec 3 02:27:58 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 03 Dec 2012 10:27:58 +0000 Subject: hg: lambda/lambda/jdk: Fix JavaDoc Message-ID: <20121203102841.C3C8647CD4@hg.openjdk.java.net> Changeset: c29a5014d3dc Author: psandoz Date: 2012-12-03 11:27 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c29a5014d3dc Fix JavaDoc ! src/share/classes/java/util/stream/StreamShape.java From georgiy.rakov at oracle.com Mon Dec 3 02:42:22 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Mon, 03 Dec 2012 14:42:22 +0400 Subject: uniqueElements in parallel mode - encounter order In-Reply-To: References: <50B8C220.6030909@oracle.com> Message-ID: <50BC820E.6060601@oracle.com> We work with promoted build 64. To be more precise the build I use for developing was downloaded from: http://jre.us.oracle.com/java/re/lambda/8/promoted/ea/b64/bundles/windows-amd64/lambda-8-b64-windows-amd64-05_nov_2012.zip We would appreciate greatly if you could promote new build with all the fixes. Thanks, Georgiy. On 30.11.2012 18:54, Paul Sandoz wrote: > What revision are you working from? > > I don't observe such behaviour from the tip, encounter order is preserved for both sequential and parallel streams. > > Example output: > > [testng] [1, 1, 8, 0, 1, 3, 5, 6, 5, 3, 9, 1, 5, 9, 8, 6, 6, 4, 7, 4, 4, 2, 7, 6, 7, 5, 0, 4, 0, 9, 7, 4, 1, 2, 5, 4, 4, 4, 5, 4, 3, 5, 4, 1, 9, 2, 2, 4, 0, 3, 6, 8, 0, 3, 6, 3, 1, 3, 2, 8, 7, 8, 2, 6, 5, 8, 2, 4, 4, 4, 0, 8, 3, 0, 2, 5, 0, 3, 8, 0, 9, 6, 7, 5, 1, 6, 5, 1, 0, 0, 9, 7, 1, 9, 7, 4, 3, 8, 8, 9, 8, 7, 1, 1, 7, 6, 0, 2, 3, 8, 2, 9, 7, 6, 1, 1, 5, 4, 9, 8, 3, 8, 2, 5, 9, 3, 1, 5, 3, 8, 5, 5, 3, 1, 3, 4, 7, 5, 9, 8, 8, 7, 8, 1, 2, 3, 2, 1, 9, 7, 1, 0, 2, 3, 0, 5, 3, 1, 6, 7, 3, 6, 3, 7, 7, 4, 4, 2, 9, 5, 7, 9, 2, 6, 5, 5, 4, 0, 0, 9, 0, 0, 8, 3, 7, 2, 8, 0, 6, 9, 3, 9, 8, 3, 8, 0, 8, 8, 1, 6, 5, 2, 0, 5, 1, 8, 8, 7, 5, 3, 0, 9, 1, 0, 2, 6, 0, 4, 0, 6, 9, 9, 8, 4, 4, 4, 2, 8, 2, 2, 9, 9, 0, 6, 3, 4, 7, 9, 2, 4, 4, 2, 1, 6, 6, 2, 6, 5, 4, 2, 6, 7, 1, 5, 6, 6, 9, 2, 9, 9, 2, 9, 5, 1, 5, 7, 7, 9, 3, 6, 5, 3, 4, 7, 7, 2, 6, 7, 1, 6, 1, 1, 3, 8, 0, 6, 4, 2, 0, 9, 0, 7, 1, 6, 7, 0, 5, 3, 8, 7] > [testng] [1, 8, 0, 3, 5, 6, 9, 4, 7, 2] > > Assuming that the input to the uniqueElements operation is not already sorted and declared as such then the implementation uses a LinkedHashSet or Set (if order is to be preserved or not respectively) to hold unique elements. It never explicitly sorts the input. > > Paul. > > On Nov 30, 2012, at 3:26 PM, Georgiy Rakov wrote: > >> Hello, >> * >> uniqueElements()* method working in parallel mode does not preserve encounter order now. Consider following code. *result *will always contain sorted numbers in spite of shuffling, i. e. [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]. I could suppose this is the used algorithm artifact. >> >> import java.util.ArrayList; >> import java.util.Arrays; >> import java.util.Collections; >> >> public class UniqueElementsIssue1 { >> public static void main(String arg[]) { >> ArrayList data = new ArrayList<>(); >> for (int i = 0; i<10; ++i) { >> for (int k = 0; k<30; ++k) { >> data.add(i); >> } >> } >> Collections.shuffle(data); >> ArrayList result = new ArrayList<>(); >> Arrays.parallel(data.toArray(new >> Integer[0])).uniqueElements().into(result); >> } >> } >> >> >> While for sequential mode (Arrays.asStream) the encounter order is preserved. >> >> Could you please tell if this is considered as expected behavior and will be showed in spec; for instance something like following could be there. >> /Having been called on stream in sequential mode, UniqueElements preserve encounter order. >> Having been called on stream in parallel mode, UniqueElements doesn't preserve encounter order. >> / >> The code above is attached for your convenience. >> >> Thanks, >> Georgiy. >> > From paul.sandoz at oracle.com Mon Dec 3 05:15:51 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 03 Dec 2012 13:15:51 +0000 Subject: hg: lambda/lambda/jdk: Take into account flags of current op to determine size. Message-ID: <20121203131655.1D3AA47CDA@hg.openjdk.java.net> Changeset: 1cc8392dcb14 Author: psandoz Date: 2012-12-03 14:14 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1cc8392dcb14 Take into account flags of current op to determine size. ! src/share/classes/java/util/stream/op/IntermediateOp.java From paul.sandoz at oracle.com Mon Dec 3 07:59:49 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 03 Dec 2012 15:59:49 +0000 Subject: hg: lambda/lambda/jdk: - ensure null values are retained Message-ID: <20121203160019.42F8947CE6@hg.openjdk.java.net> Changeset: 8d6fc90e7bbf Author: psandoz Date: 2012-12-03 16:57 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8d6fc90e7bbf - ensure null values are retained - add very simple data provider for combination of numbers and null values ! src/share/classes/java/util/stream/op/UniqOp.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UniqOpTest.java From maurizio.cimadamore at oracle.com Mon Dec 3 08:11:44 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 03 Dec 2012 16:11:44 +0000 Subject: hg: lambda/lambda/langtools: Enhancement: Add support for static interface methods Message-ID: <20121203161153.8067147CE9@hg.openjdk.java.net> Changeset: 67030038d40b Author: mcimadamore Date: 2012-12-03 15:32 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/67030038d40b Enhancement: Add support for static interface methods This patch adds support for static interface methods. Hiding rules are simpler than those for static class methods, as a static interface method cannot be inherithed. ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/defaultMethods/hiding/InterfaceMethodHidingTest.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java ! test/tools/javac/diags/examples.not-yet.txt From maurizio.cimadamore at oracle.com Mon Dec 3 09:23:06 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 03 Dec 2012 17:23:06 +0000 Subject: hg: lambda/lambda/langtools: Fix missing import Message-ID: <20121203172313.D59E647CEF@hg.openjdk.java.net> Changeset: 7edd4d92d95c Author: mcimadamore Date: 2012-12-03 17:22 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7edd4d92d95c Fix missing import ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java From zhong.j.yu at gmail.com Mon Dec 3 09:27:45 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Mon, 3 Dec 2012 11:27:45 -0600 Subject: hg: lambda/lambda/langtools: Enhancement: Add support for static interface methods In-Reply-To: <20121203161153.8067147CE9@hg.openjdk.java.net> References: <20121203161153.8067147CE9@hg.openjdk.java.net> Message-ID: On Mon, Dec 3, 2012 at 10:11 AM, wrote: > Changeset: 67030038d40b > Author: mcimadamore > Date: 2012-12-03 15:32 +0000 > URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/67030038d40b > > Enhancement: Add support for static interface methods wow, this is fantastic. > This patch adds support for static interface methods. > Hiding rules are simpler than those for static class methods, as a static interface method cannot be inherithed. > > ! src/share/classes/com/sun/tools/javac/code/Flags.java > ! src/share/classes/com/sun/tools/javac/code/Source.java > ! src/share/classes/com/sun/tools/javac/code/Symbol.java > ! src/share/classes/com/sun/tools/javac/comp/Attr.java > ! src/share/classes/com/sun/tools/javac/comp/Check.java > ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java > ! src/share/classes/com/sun/tools/javac/resources/compiler.properties > + test/tools/javac/defaultMethods/hiding/InterfaceMethodHidingTest.java > ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java > ! test/tools/javac/diags/examples.not-yet.txt > > From maurizio.cimadamore at oracle.com Mon Dec 3 09:31:02 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 03 Dec 2012 17:31:02 +0000 Subject: hg: lambda/lambda/langtools: Enhancement: Add support for static interface methods In-Reply-To: References: <20121203161153.8067147CE9@hg.openjdk.java.net> Message-ID: <50BCE1D6.5040909@oracle.com> On 03/12/12 17:27, Zhong Yu wrote: > On Mon, Dec 3, 2012 at 10:11 AM, wrote: >> Changeset: 67030038d40b >> Author: mcimadamore >> Date: 2012-12-03 15:32 +0000 >> URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/67030038d40b >> >> Enhancement: Add support for static interface methods > wow, this is fantastic. Long due ;-) Btw - for those willing to experiment, I noticed that if you try to run code that calls static interface method you get a verifier error because of a verifier glitch (the verifier doesn't like an interface method CP entry on an invokestatic) - so you need to run with -Xverify:none, for now. Maurizio > >> This patch adds support for static interface methods. >> Hiding rules are simpler than those for static class methods, as a static interface method cannot be inherithed. >> >> ! src/share/classes/com/sun/tools/javac/code/Flags.java >> ! src/share/classes/com/sun/tools/javac/code/Source.java >> ! src/share/classes/com/sun/tools/javac/code/Symbol.java >> ! src/share/classes/com/sun/tools/javac/comp/Attr.java >> ! src/share/classes/com/sun/tools/javac/comp/Check.java >> ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java >> ! src/share/classes/com/sun/tools/javac/resources/compiler.properties >> + test/tools/javac/defaultMethods/hiding/InterfaceMethodHidingTest.java >> ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java >> ! test/tools/javac/diags/examples.not-yet.txt >> >> From forax at univ-mlv.fr Tue Dec 4 00:25:04 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 04 Dec 2012 09:25:04 +0100 Subject: hg: lambda/lambda/jdk: - ensure null values are retained In-Reply-To: <20121203160019.42F8947CE6@hg.openjdk.java.net> References: <20121203160019.42F8947CE6@hg.openjdk.java.net> Message-ID: <50BDB360.1000100@univ-mlv.fr> On 12/03/2012 04:59 PM, paul.sandoz at oracle.com wrote: > Changeset: 8d6fc90e7bbf > Author: psandoz > Date: 2012-12-03 16:57 +0100 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8d6fc90e7bbf > > - ensure null values are retained > - add very simple data provider for combination of numbers and null values > > ! src/share/classes/java/util/stream/op/UniqOp.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UniqOpTest.java > > Hi Paul, that's not the good way(TM) to handle null. A better approach is to use the Null Object design pattern, i.e. having a constant final field Object with a known object and each time a null is sent, null is replaced by the Object and each time the element need to be sent, if element value is equals to the known Object, null is sent. You can take a look to IdentityHashMap.maskNull/unmaskNull [1] which already implements this pattern. This can be done locally to each ops or globally for the whole pipeline, the former solution is enough in my opinion. The null object pattern is better because it adds only two checks on variable that are already in register if the code never see a null (the usual case). Your solution require to load/store value from the RAM because the VM will not able to optimize this code (inlining is often defeated due to the fact that the call between ops is a virtual call). cheers, R?mi [1] http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/df5619994dc3/src/share/classes/java/util/IdentityHashMap.java From mcnepp02 at googlemail.com Tue Dec 4 01:01:09 2012 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Tue, 4 Dec 2012 10:01:09 +0100 Subject: Why still retain Iterator.remove() Message-ID: I have to admit that until very recently I'd thought that java.util.streams.Stream extends java.util.Iterable. While toying with one of the latest JDK8 snapshots, I realized my mistake. Immediately a question pops up: Why does java.util.Stream still return a java.util.Iterator with its "optional" remove() method? As far as I can see, Iterator.remove() is nowhere implemented in the entire streams package, thus it always throws UnsupportedOperationException. If Stream isn't bound by Iterable's contract anymore, why not simply return a java.util.StreamIterator without remove()? (Then, of course, java.util.Iterator could be refactored to exend StreamIterator) To me, this looks like a good oppurtunity to clean things up and do away with one of Java's little idiosyncrasies. From paul.sandoz at oracle.com Tue Dec 4 01:44:05 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 4 Dec 2012 10:44:05 +0100 Subject: Why still retain Iterator.remove() In-Reply-To: References: Message-ID: <91F20822-A836-4703-B00F-A78D12A51094@oracle.com> On Dec 4, 2012, at 10:01 AM, Gernot Neppert wrote: > I have to admit that until very recently I'd thought that > java.util.streams.Stream extends java.util.Iterable. > While toying with one of the latest JDK8 snapshots, I realized my mistake. > Immediately a question pops up: > Why does java.util.Stream still return a java.util.Iterator with its > "optional" remove() method? > As far as I can see, Iterator.remove() is nowhere implemented in the entire > streams package, thus it always throws UnsupportedOperationException. > > If Stream isn't bound by Iterable's contract anymore, why not simply return > a java.util.StreamIterator without remove()? > For interoperability and convenience, many things consume Iterator. The Stream.iterator() method is an "escape hatch" to consume the stream. > (Then, of course, java.util.Iterator could be refactored to exend > StreamIterator) > > To me, this looks like a good oppurtunity to clean things up and do away > with one of Java's little idiosyncrasies. > If we were able to wind the clock back that might be possible :-) Thanks to default methods producers of Iterator are no longer required to implement the optional remove(). Paul. From paul.sandoz at oracle.com Tue Dec 4 02:44:00 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 4 Dec 2012 11:44:00 +0100 Subject: hg: lambda/lambda/jdk: - ensure null values are retained In-Reply-To: <50BDB360.1000100@univ-mlv.fr> References: <20121203160019.42F8947CE6@hg.openjdk.java.net> <50BDB360.1000100@univ-mlv.fr> Message-ID: <49B6AEF6-6D22-46AB-90BF-F8B86B2E210F@oracle.com> Hi Remi, Many thanks, that is just the kind of VM-perspective advice i was looking for. I was assuming that the VM would be able to somehow inline the hot path to the else block. So you are suggesting something like this: T _t = (T) maskNull(t); if (lastSeen == null || !lastSeen.equals(_t)) { lastSeen = _t; downstream.accept(t); } rather than: if (t == null) { if (!seenNull) { seenNull = true; downstream.accept(lastSeen = null); } } else if (lastSeen == null || !t.equals(lastSeen)) { downstream.accept(lastSeen = t); } Paul. On Dec 4, 2012, at 9:25 AM, Remi Forax wrote: > On 12/03/2012 04:59 PM, paul.sandoz at oracle.com wrote: >> Changeset: 8d6fc90e7bbf >> Author: psandoz >> Date: 2012-12-03 16:57 +0100 >> URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8d6fc90e7bbf >> >> - ensure null values are retained >> - add very simple data provider for combination of numbers and null values >> >> ! src/share/classes/java/util/stream/op/UniqOp.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UniqOpTest.java >> >> > > Hi Paul, > that's not the good way(TM) to handle null. > > A better approach is to use the Null Object design pattern, i.e. > having a constant final field Object with a known object and each time > a null is sent, null is replaced by the Object and each time the element > need to be sent, if element value is equals to the known Object, null is > sent. > You can take a look to IdentityHashMap.maskNull/unmaskNull [1] which already > implements this pattern. > > This can be done locally to each ops or globally for the whole pipeline, > the former solution is enough in my opinion. > > The null object pattern is better because it adds only two checks on > variable that are already in register > if the code never see a null (the usual case). Your solution require to > load/store value from the RAM > because the VM will not able to optimize this code (inlining is often > defeated due to the fact that the call > between ops is a virtual call). > > cheers, > R?mi > > [1] > http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/df5619994dc3/src/share/classes/java/util/IdentityHashMap.java > > From paul.sandoz at oracle.com Tue Dec 4 05:01:29 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 04 Dec 2012 13:01:29 +0000 Subject: hg: lambda/lambda/jdk: IntStream.unordered() that clears order for downstream ops. Message-ID: <20121204130254.872C447D70@hg.openjdk.java.net> Changeset: c8852f15b42c Author: psandoz Date: 2012-12-04 14:00 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c8852f15b42c IntStream.unordered() that clears order for downstream ops. ! src/share/classes/java/util/stream/op/FlagDeclaringOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/TestFlagExpectedOp.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UnorderedStreamTest.java From forax at univ-mlv.fr Tue Dec 4 05:26:03 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 04 Dec 2012 14:26:03 +0100 Subject: hg: lambda/lambda/jdk: - ensure null values are retained In-Reply-To: <49B6AEF6-6D22-46AB-90BF-F8B86B2E210F@oracle.com> References: <20121203160019.42F8947CE6@hg.openjdk.java.net> <50BDB360.1000100@univ-mlv.fr> <49B6AEF6-6D22-46AB-90BF-F8B86B2E210F@oracle.com> Message-ID: <50BDF9EB.20101@univ-mlv.fr> On 12/04/2012 11:44 AM, Paul Sandoz wrote: > Hi Remi, > > Many thanks, that is just the kind of VM-perspective advice i was looking for. I was assuming that the VM would be able to somehow inline the hot path to the else block. yes, but you don't need a supplementary field for that. > > So you are suggesting something like this: > > T _t = (T) maskNull(t); > if (lastSeen == null || !lastSeen.equals(_t)) { > lastSeen = _t; > downstream.accept(t); > } I was thinking to something like this: return new Sink.ChainedReference(sink) { private Object lastSeen; @Override public void begin(long size) { lastSeen = null; // not needed if end() is called in a finally ? downstream.begin(-1); } @Override public void end() { lastSeen = null; downstream.end(); } @Override public void accept(T t) { if (t == null) { if (lastSeen != NULL_OBJECT) { lastSeen = NULL_OBJECT downstream.accept(null); } } else if (lastSeen == null || !t.equals(lastSeen)) { lastSeen = t; downstream.accept((T)t); } } }; > > rather than: > > if (t == null) { > if (!seenNull) { > seenNull = true; > downstream.accept(lastSeen = null); > } > } else if (lastSeen == null || !t.equals(lastSeen)) { > downstream.accept(lastSeen = t); > } > > Paul. R?mi From paul.sandoz at oracle.com Tue Dec 4 05:53:44 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 4 Dec 2012 14:53:44 +0100 Subject: hg: lambda/lambda/jdk: - ensure null values are retained In-Reply-To: <50BDF9EB.20101@univ-mlv.fr> References: <20121203160019.42F8947CE6@hg.openjdk.java.net> <50BDB360.1000100@univ-mlv.fr> <49B6AEF6-6D22-46AB-90BF-F8B86B2E210F@oracle.com> <50BDF9EB.20101@univ-mlv.fr> Message-ID: On Dec 4, 2012, at 2:26 PM, Remi Forax wrote: > On 12/04/2012 11:44 AM, Paul Sandoz wrote: >> Hi Remi, >> >> Many thanks, that is just the kind of VM-perspective advice i was looking for. I was assuming that the VM would be able to somehow inline the hot path to the else block. > > yes, but you don't need a supplementary field for that. > Right, but subjectively i think it is marginally clearer code. >> >> So you are suggesting something like this: >> >> T _t = (T) maskNull(t); >> if (lastSeen == null || !lastSeen.equals(_t)) { >> lastSeen = _t; >> downstream.accept(t); >> } > > I was thinking to something like this: > > return new Sink.ChainedReference(sink) { > private Object lastSeen; > > @Override > public void begin(long size) { > lastSeen = null; // not needed if end() is called in a finally ? It's not needed. > downstream.begin(-1); > } > > @Override > public void end() { > lastSeen = null; > downstream.end(); > } > > @Override > public void accept(T t) { > if (t == null) { > if (lastSeen != NULL_OBJECT) { > lastSeen = NULL_OBJECT > downstream.accept(null); > } > } else if (lastSeen == null || !t.equals(lastSeen)) { > lastSeen = t; > downstream.accept((T)t); > } > } > }; > If one assumes nulls are rare is there any performance advantage (beyond the extra field not being used) to using the null object design pattern in this context? I am trying and failing to correlate what you say below with the code base: "Your solution require to load/store value from the RAM because the VM will not able to optimize this code (inlining is often defeated due to the fact that the call between ops is a virtual call)." Paul. >> >> rather than: >> >> if (t == null) { >> if (!seenNull) { >> seenNull = true; >> downstream.accept(lastSeen = null); >> } >> } else if (lastSeen == null || !t.equals(lastSeen)) { >> downstream.accept(lastSeen = t); >> } >> >> Paul. > > R?mi > > From peter.levart at gmail.com Tue Dec 4 06:00:11 2012 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 04 Dec 2012 15:00:11 +0100 Subject: hg: lambda/lambda/jdk: - ensure null values are retained In-Reply-To: <50BDF9EB.20101@univ-mlv.fr> References: <20121203160019.42F8947CE6@hg.openjdk.java.net> <50BDB360.1000100@univ-mlv.fr> <49B6AEF6-6D22-46AB-90BF-F8B86B2E210F@oracle.com> <50BDF9EB.20101@univ-mlv.fr> Message-ID: <50BE01EB.1060407@gmail.com> Hi Remi, Paul, What about vice-versa: Like this: private static final Object NONE = new Object(); ... return new Sink.ChainedReference(sink) { private Object lastSeen; @Override public void begin(long size) { lastSeen = NONE; // not needed if end() is called in a finally ? downstream.begin(-1); } @Override public void end() { lastSeen = NONE; downstream.end(); } @Override public void accept(T t) { if (!Objects.equals(t, lastSeen)) { lastSeen = t; downstream.accept(t); } } }; On 12/04/2012 02:26 PM, Remi Forax wrote: > I was thinking to something like this: > > return new Sink.ChainedReference(sink) { > private Object lastSeen; > > @Override > public void begin(long size) { > lastSeen = null; // not needed if end() is called in a finally ? > downstream.begin(-1); > } > > @Override > public void end() { > lastSeen = null; > downstream.end(); > } > > @Override > public void accept(T t) { > if (t == null) { > if (lastSeen != NULL_OBJECT) { > lastSeen = NULL_OBJECT > downstream.accept(null); > } > } else if (lastSeen == null || !t.equals(lastSeen)) { > lastSeen = t; > downstream.accept((T)t); > } > } > }; From dmitry.bessonov at oracle.com Tue Dec 4 06:05:58 2012 From: dmitry.bessonov at oracle.com (Dmitry Bessonov) Date: Tue, 04 Dec 2012 18:05:58 +0400 Subject: First element of a parallel stream? +possible bug report Message-ID: <50BE0346.4020909@oracle.com> 1)Question: Is the result of the following chain of operations defined and should be the same on all hardware/implementations? Arrays.asList("first", "second", "last").parallel().findFirst(); 2) Report: Slightly modified version throws NPE (with the yesterday's state of the repo) : Arrays.asList("first", "second", null, "last").parallel().findFirst(); -Dmitry From forax at univ-mlv.fr Tue Dec 4 06:12:21 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 04 Dec 2012 15:12:21 +0100 Subject: hg: lambda/lambda/jdk: - ensure null values are retained In-Reply-To: <50BE01EB.1060407@gmail.com> References: <20121203160019.42F8947CE6@hg.openjdk.java.net> <50BDB360.1000100@univ-mlv.fr> <49B6AEF6-6D22-46AB-90BF-F8B86B2E210F@oracle.com> <50BDF9EB.20101@univ-mlv.fr> <50BE01EB.1060407@gmail.com> Message-ID: <50BE04C5.5070001@univ-mlv.fr> On 12/04/2012 03:00 PM, Peter Levart wrote: > Hi Remi, Paul, > > What about vice-versa: Hi Peter, good idea ! we still need a if (t==null) in accept() and not use Objects.equals because we want the VM to profile the null in accept() and not in Objects.equals(). R?mi > > Like this: > > private static final Object NONE = new Object(); > ... > > return new Sink.ChainedReference(sink) { > private Object lastSeen; > > @Override > public void begin(long size) { > lastSeen = NONE; // not needed if end() is > called in a finally ? > downstream.begin(-1); > } > > @Override > public void end() { > lastSeen = NONE; > downstream.end(); > } > > @Override > public void accept(T t) { > if (!Objects.equals(t, lastSeen)) { > lastSeen = t; > downstream.accept(t); > } > } > }; > > > On 12/04/2012 02:26 PM, Remi Forax wrote: >> I was thinking to something like this: >> >> return new Sink.ChainedReference(sink) { >> private Object lastSeen; >> >> @Override >> public void begin(long size) { >> lastSeen = null; // not needed if >> end() is called in a finally ? >> downstream.begin(-1); >> } >> >> @Override >> public void end() { >> lastSeen = null; >> downstream.end(); >> } >> >> @Override >> public void accept(T t) { >> if (t == null) { >> if (lastSeen != NULL_OBJECT) { >> lastSeen = NULL_OBJECT >> downstream.accept(null); >> } >> } else if (lastSeen == null || >> !t.equals(lastSeen)) { >> lastSeen = t; >> downstream.accept((T)t); >> } >> } >> }; > > From georgiy.rakov at oracle.com Tue Dec 4 07:24:13 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Tue, 04 Dec 2012 19:24:13 +0400 Subject: Stream.cumulate issue Message-ID: <50BE159D.4090506@oracle.com> Hello, cumulate().toArray() seems not to work properly with nulls. Consider following code: import java.util.Arrays; import java.util.stream.Stream; public class CumulateIssue { public static void main(String [] argv) { Stream stream = Arrays.parallel(new Object[]{null, null, null, null}).cumulate((a, b)->3); System.out.println(Arrays.toString(stream.toArray())); } } It obviously should output: [null, 3, 3, 3] But instead it outputs: [null, null, null, null] I could suppose it's a bug. Please confirm if it is. I use nightly build of November 5. The code is attached for your convenience. Thanks, Georgiy. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: CumulateIssue.java Url: http://mail.openjdk.java.net/pipermail/lambda-dev/attachments/20121204/7823977b/CumulateIssue.java From mike.duigou at oracle.com Tue Dec 4 12:21:44 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 04 Dec 2012 20:21:44 +0000 Subject: hg: lambda/lambda/corba: 2 new changesets Message-ID: <20121204202148.19FEC47D9B@hg.openjdk.java.net> Changeset: 394515ad2a55 Author: katleman Date: 2012-11-29 11:29 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/394515ad2a55 Added tag jdk8-b66 for changeset 65771ad1ca55 ! .hgtags Changeset: 6004438008e0 Author: mduigou Date: 2012-12-04 11:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/6004438008e0 Merge ! .hgtags From mike.duigou at oracle.com Tue Dec 4 12:21:44 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 04 Dec 2012 20:21:44 +0000 Subject: hg: lambda/lambda/jaxws: 2 new changesets Message-ID: <20121204202153.156C947D9E@hg.openjdk.java.net> Changeset: eb06aa51dfc2 Author: katleman Date: 2012-11-29 11:30 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/eb06aa51dfc2 Added tag jdk8-b66 for changeset 3eb7f11cb4e0 ! .hgtags Changeset: e64f4eda4df6 Author: mduigou Date: 2012-12-04 11:44 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/e64f4eda4df6 Merge ! .hgtags From mike.duigou at oracle.com Tue Dec 4 12:21:46 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 04 Dec 2012 20:21:46 +0000 Subject: hg: lambda/lambda/jaxp: 2 new changesets Message-ID: <20121204202154.BF5A747DA1@hg.openjdk.java.net> Changeset: 83df3493ca3c Author: katleman Date: 2012-11-29 11:30 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/83df3493ca3c Added tag jdk8-b66 for changeset e6af1ad464e3 ! .hgtags Changeset: 84ded1ab12a8 Author: mduigou Date: 2012-12-04 11:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/84ded1ab12a8 Merge ! .hgtags From mike.duigou at oracle.com Tue Dec 4 12:22:10 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 04 Dec 2012 20:22:10 +0000 Subject: hg: lambda/lambda/hotspot: 130 new changesets Message-ID: <20121204202639.610EB47DA7@hg.openjdk.java.net> Changeset: c3e799c37717 Author: vlivanov Date: 2012-10-05 18:57 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c3e799c37717 7177003: C1: LogCompilation support Summary: add LogCompilation support in C1 - both client and tiered mode. Reviewed-by: twisti, kvn ! src/os/linux/vm/vmError_linux.cpp ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileLog.cpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/ostream.cpp Changeset: 9a9b6e05ffb4 Author: vlivanov Date: 2012-10-05 19:29 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9a9b6e05ffb4 8000232: NPG: SIGSEGV in Dependencies::DepStream::check_klass_dependency on solaris-x64 Summary: Move decoding into Dependencies::DepStream::argument, so no caller could see encoded context value (NULL) anymore. Reviewed-by: twisti, kvn ! src/share/vm/code/dependencies.cpp Changeset: 9024b6b53ec2 Author: vlivanov Date: 2012-10-05 19:44 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9024b6b53ec2 8000485: Hotspot build fails in Solaris Studio IDE when building dtrace Summary: Prepend '.' to the existing native library path Reviewed-by: kvn, sspitsyn ! make/bsd/makefiles/dtrace.make ! make/solaris/makefiles/dtrace.make Changeset: 377508648226 Author: vlivanov Date: 2012-10-08 13:02 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/377508648226 8000313: C2 should use jlong for 64bit values Summary: Replace all occurrences of long with jlong in C2 code. Reviewed-by: kvn, twisti ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/phaseX.hpp Changeset: 65d07d9ee446 Author: twisti Date: 2012-10-08 17:04 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/65d07d9ee446 8000263: JSR 292: signature types may appear to be unloaded Reviewed-by: kvn, jrose ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.hpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/runtime/globals.hpp Changeset: 8e47bac5643a Author: roland Date: 2012-10-09 10:11 +0200 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8e47bac5643a 7054512: Compress class pointers after perm gen removal Summary: support of compress class pointers in the compilers. Reviewed-by: kvn, twisti ! agent/src/share/classes/sun/jvm/hotspot/debugger/Address.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/Debugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/JVMDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/dummy/DummyAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerServer.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgAddress.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Array.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Instance.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MetadataField.java + agent/src/share/classes/sun/jvm/hotspot/oops/NarrowKlassField.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java ! agent/src/share/classes/sun/jvm/hotspot/oops/java_lang_Class.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/RobustOopDeterminator.java ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/relocInfo_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/bsd/dtrace/generateJvmOffsets.cpp ! src/os/bsd/dtrace/jhelper.d ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/instanceOop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/matcher.hpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/subnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/globalDefinitions.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: f6badecb7ea7 Author: vlivanov Date: 2012-10-09 12:40 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f6badecb7ea7 7199654: Remove LoadUI2LNode Summary: Removed LoadUI2L node from Ideal nodes, use match rule in .ad files instead. Reviewed-by: kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/superword.cpp Changeset: d336b3173277 Author: kvn Date: 2012-10-09 16:09 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d336b3173277 8000592: Improve adlc usability Summary: several changes to adlc to improve its usability Reviewed-by: kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/archDesc.hpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp Changeset: 94e9408dbf50 Author: roland Date: 2012-10-11 18:21 +0200 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/94e9408dbf50 8000753: compiler/6912517 crashes on 64bit sparc with compressed oops off Summary: code generated by c1 for getClass intrinsic broken when klass field is loaded on 64bit with compressed klass off. Reviewed-by: kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp Changeset: 19eb999cb72c Author: twisti Date: 2012-10-11 14:46 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/19eb999cb72c 8000740: remove LinkWellKnownClasses Reviewed-by: kvn, jrose ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/runtime/globals.hpp Changeset: d804e148cff8 Author: kvn Date: 2012-10-12 09:22 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d804e148cff8 Merge ! make/bsd/makefiles/dtrace.make ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_FrameMap_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp ! src/share/vm/c1/c1_GraphBuilder.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: fb19af007ffc Author: jprovino Date: 2012-10-10 14:35 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/fb19af007ffc 7189254: Change makefiles for more flexibility to override defaults Summary: Change makefiles so that targets and parameters can be overridden by alternate makefiles. Reviewed-by: dholmes, coleenp ! make/Makefile ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/defs.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/ia64.make + make/bsd/makefiles/minimal1.make ! make/bsd/makefiles/vm.make ! make/defs.make + make/excludeSrc.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/defs.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/ia64.make + make/linux/makefiles/minimal1.make ! make/linux/makefiles/vm.make ! make/windows/makefiles/defs.make ! src/os/solaris/vm/os_solaris.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/metaspaceShared.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/forte.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnter.xsl ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/prims/jvmtiThreadState.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/globals_extension.hpp ! src/share/vm/runtime/init.cpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/diagnosticCommand.hpp ! src/share/vm/services/heapDumper.hpp ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/services/runtimeService.cpp ! src/share/vm/services/runtimeService.hpp ! src/share/vm/utilities/macros.hpp Changeset: bbeecede56dd Author: jiangli Date: 2012-10-11 14:36 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bbeecede56dd 8000459: assert(java_lang_String::is_instance(entry)) failure with various mlvm tests. Summary: Remove unneeded assert. Reviewed-by: sspitsyn, coleenp ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 9855b7e559ae Author: collins Date: 2012-10-12 10:49 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9855b7e559ae Merge ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/vm.make ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/diagnosticCommand.cpp ! src/share/vm/services/management.cpp Changeset: 5876f980ea19 Author: collins Date: 2012-10-12 11:31 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5876f980ea19 Merge ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b261523fe66c Author: amurillo Date: 2012-10-12 13:55 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b261523fe66c Merge Changeset: 4547dc71db76 Author: amurillo Date: 2012-10-12 13:55 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4547dc71db76 Added tag hs25-b05 for changeset b261523fe66c ! .hgtags Changeset: fcbdaeb69946 Author: katleman Date: 2012-10-18 11:08 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/fcbdaeb69946 Added tag jdk8-b61 for changeset 4547dc71db76 ! .hgtags Changeset: 58fbf2da3c16 Author: amurillo Date: 2012-10-12 14:06 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/58fbf2da3c16 8000834: new hotspot build - hs25-b06 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 8a5ea0a9ccc4 Author: johnc Date: 2012-10-06 01:17 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8a5ea0a9ccc4 7127708: G1: change task num types from int to uint in concurrent mark Summary: Change the type of various task num fields, parameters etc to unsigned and rename them to be more consistent with the other collectors. Code changes were also reviewed by Vitaly Davidovich. Reviewed-by: johnc Contributed-by: Kaushik Srenevasan ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.inline.hpp Changeset: 04155d9c8c76 Author: johnc Date: 2012-10-08 09:12 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/04155d9c8c76 8000358: G1: metaspace information not printed in PrintHeapAtGC output nor in hs_err file Summary: Missing call to MetaspaceAux::print_on() in G1CollectedHeap::print_on(). Reviewed-by: azeemj, jmasa Contributed-by: Mikael Gerdin ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: dd2b66d09ccd Author: stefank Date: 2012-10-09 22:12 +0200 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/dd2b66d09ccd 8000659: NPG: ClassCastExceptions are unexpectedly thrown when testing nashorn Summary: Treat the oops in invoke_method_table() as strong roots when ClassUnloading is enabled. Reviewed-by: kamg, coleenp ! src/share/vm/classfile/systemDictionary.cpp Changeset: 4202510ee0fe Author: johnc Date: 2012-10-15 10:02 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4202510ee0fe 8000831: Heap verification output incorrect/incomplete Summary: Restore non-silent output of heap verification. Reviewed-by: ysr, brutisso, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/utilities/debug.cpp Changeset: 633ba56cb013 Author: jmasa Date: 2012-10-17 13:59 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/633ba56cb013 Merge ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmCMSOperations.cpp ! src/share/vm/memory/universe.hpp Changeset: e0ea0e94c23c Author: kevinw Date: 2012-10-15 16:48 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e0ea0e94c23c 7195151: Multiplatform tescase for 6929067 Reviewed-by: kamg, kvn ! test/runtime/6929067/Test6929067.sh Changeset: e52361627b65 Author: coleenp Date: 2012-10-15 22:33 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e52361627b65 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/runtime/globals.hpp Changeset: 045cb62046a7 Author: rbackman Date: 2012-08-28 15:15 +0200 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/045cb62046a7 7093328: JVMTI: jvmtiPrimitiveFieldCallback always report 0's for static primitives Reviewed-by: dholmes, dcubed ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 7b5885dadbdc Author: nloodin Date: 2012-10-17 17:36 +0200 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7b5885dadbdc 8000617: It should be possible to allocate memory without the VM dying. Reviewed-by: coleenp, kamg ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/allocation.inline.hpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: e8c79c2ba3f3 Author: coleenp Date: 2012-10-18 12:29 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e8c79c2ba3f3 Merge Changeset: d0337c31c8be Author: amurillo Date: 2012-10-19 11:03 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d0337c31c8be Merge Changeset: dccd40de8db1 Author: amurillo Date: 2012-10-19 11:03 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/dccd40de8db1 Added tag hs25-b06 for changeset d0337c31c8be ! .hgtags Changeset: 556dd9e475c6 Author: katleman Date: 2012-10-25 09:53 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/556dd9e475c6 Added tag jdk8-b62 for changeset dccd40de8db1 ! .hgtags Changeset: d0e7716b179e Author: amurillo Date: 2012-10-19 11:26 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d0e7716b179e 8001176: new hotspot build - hs25-b07 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 85916677fc22 Author: coleenp Date: 2012-10-18 13:08 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/85916677fc22 7188233: UseVMInterruptibleIO flag deprecate for JDK8 Summary: The -XX:+UseVMInterruptibleIO flag is deprecated for JDK8. The flag will still enable Interruptible IO on Solaris, but users will get a warning. Reviewed-by: dholmes, acorn, alanb Contributed-by: harold.seigel at oracle.com ! src/share/vm/runtime/arguments.cpp Changeset: 8ebcedb7604d Author: coleenp Date: 2012-10-18 13:09 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8ebcedb7604d 7053130: hs_err file does not record specified CLASSPATH Summary: Added code to write the value of the java.class.path property to the hs_err file. Reviewed-by: kmo, dholmes, kvn Contributed-by: harold.seigel at oracle.com ! src/share/vm/runtime/arguments.cpp Changeset: c7957b458bf8 Author: minqi Date: 2012-10-19 08:56 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c7957b458bf8 8000818: SA constant pool need to reference to reference map after permgen removal Summary: After permgen removal, constant pool changed to put _ldc and _ldc_w (fast_ldc and fast_ldcw) index to reference map, no longer calculated via constant pool cache. Reviewed-by: coleenp, sspitsyn, dholmes Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java Changeset: 8eeffbc22f10 Author: minqi Date: 2012-10-19 08:58 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8eeffbc22f10 8001055: Bytes.swap should follow big endian Summary: This is a mistake change in 6879063 about Bytes.swap. Java byte code order always follows big endian, but in that change, assume they follow native platform order that is not right. Reviewed-by: coleenp, sspitsyn, dholmes Contributed-by: yumin.qi at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/runtime/Bytes.java Changeset: 716c64bda5ba Author: zgu Date: 2012-10-19 21:40 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/716c64bda5ba 7199092: NMT: NMT needs to deal overlapped virtual memory ranges Summary: Enhanced virtual memory tracking to track committed regions as well as reserved regions, so NMT now can generate virtual memory map. Reviewed-by: acorn, coleenp ! src/os/bsd/vm/perfMemory_bsd.cpp ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memBaseline.hpp ! src/share/vm/services/memPtr.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: b988bff99b38 Author: zgu Date: 2012-10-19 18:55 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b988bff99b38 Merge Changeset: 80f44792c0c9 Author: coleenp Date: 2012-10-22 12:01 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/80f44792c0c9 Merge Changeset: 685df3c6f84b Author: jmasa Date: 2012-09-18 23:35 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/685df3c6f84b 7045397: NPG: Add freelists to class loader arenas. Reviewed-by: coleenp, stefank, jprovino, ohair ! make/excludeSrc.make + src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.cpp + src/share/vm/gc_implementation/concurrentMarkSweep/adaptiveFreeList.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/freeChunk.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/freeBlockDictionary.hpp ! src/share/vm/memory/freeList.cpp ! src/share/vm/memory/freeList.hpp + src/share/vm/memory/metablock.hpp + src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 476718ea6759 Author: jmasa Date: 2012-10-25 12:59 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/476718ea6759 8001584: NPG: Incorrect assertion in BinaryTreeDictionary::get_chunk() Reviewed-by: johnc, tamao ! src/share/vm/memory/binaryTreeDictionary.hpp Changeset: b58313cf9afd Author: jcoomes Date: 2012-10-26 08:38 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b58313cf9afd Merge Changeset: cfe522e6461c Author: kvn Date: 2012-10-17 12:09 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/cfe522e6461c 8000623: tools/javac/Diagnostics/6769027/T6769027.java crashes in PSPromotionManager::copy_to_survivor_space Summary: Fix type of method pointer load from vtable. Reviewed-by: twisti, johnc, roland ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/library_call.cpp Changeset: e81a8af10cd9 Author: kvn Date: 2012-10-18 07:06 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e81a8af10cd9 8001071: Add simple range check into VM implemenation of Unsafe access methods Summary: Add simple check in debug version of VM. Reviewed-by: twisti, johnc ! src/share/vm/prims/unsafe.cpp Changeset: aaeb9add1ab3 Author: dlong Date: 2012-10-19 14:21 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/aaeb9add1ab3 8001101: C2: more general vector rule subsetting Summary: Allow which vector rules are supported to be decided at runtime. Also a small change to allow vector types in Type::_type_info[] to apply to more platforms. Reviewed-by: kvn, twisti Contributed-by: dean.long at oracle.com ! src/share/vm/opto/type.cpp ! src/share/vm/opto/vectornode.cpp Changeset: 67f4c477c9ab Author: vlivanov Date: 2012-10-22 11:44 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/67f4c477c9ab 8000805: JMM issue: short loads are non-atomic Summary: perform transforms during IGVN phase when Load has a single user. Reviewed-by: jrose, kvn, twisti ! src/share/vm/opto/mulnode.cpp + test/compiler/8000805/Test8000805.java Changeset: fd1d564dd460 Author: twisti Date: 2012-10-22 16:56 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/fd1d564dd460 8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920) Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: b2c669fd8114 Author: kvn Date: 2012-10-23 13:06 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b2c669fd8114 8001183: incorrect results of char vectors right shift operaiton Summary: do vector right shift operation for small int types only after loads Reviewed-by: jrose, dlong ! src/cpu/x86/vm/x86.ad ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/vectornode.cpp ! test/compiler/6340864/TestByteVect.java ! test/compiler/6340864/TestIntVect.java ! test/compiler/6340864/TestLongVect.java ! test/compiler/6340864/TestShortVect.java + test/compiler/8001183/TestCharVect.java Changeset: a3ecd773a7b9 Author: kvn Date: 2012-10-24 14:33 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a3ecd773a7b9 7184394: add intrinsics to use AES instructions Summary: Use new x86 AES instructions for AESCrypt. Reviewed-by: twisti, kvn, roland Contributed-by: tom.deneau at amd.com ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.hpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/stubRoutines.cpp ! src/share/vm/runtime/stubRoutines.hpp + test/compiler/7184394/TestAESBase.java + test/compiler/7184394/TestAESDecode.java + test/compiler/7184394/TestAESEncode.java + test/compiler/7184394/TestAESMain.java Changeset: 006174cfe979 Author: kvn Date: 2012-10-25 17:32 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/006174cfe979 7163534: VM could crashes assert(false) failed: infinite EA connection graph build Summary: In case of time or iterations limit reached C2 stops EA and continue compilation without EA as it does in product VM already. Reviewed-by: twisti ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/escape.cpp Changeset: 410afdc6a07c Author: kvn Date: 2012-10-26 11:48 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/410afdc6a07c 8001635: assert(in_bb(n)) failed: must be Summary: Added missed check that Load node is in processed loop block. Reviewed-by: twisti ! src/share/vm/opto/superword.cpp Changeset: 588f08ed16cf Author: kvn Date: 2012-10-26 12:06 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/588f08ed16cf Merge ! src/share/vm/runtime/globals.hpp Changeset: dc16fe422c53 Author: amurillo Date: 2012-10-26 14:09 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/dc16fe422c53 Merge Changeset: 57c61f87a1fd Author: amurillo Date: 2012-10-26 14:09 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/57c61f87a1fd Added tag hs25-b07 for changeset dc16fe422c53 ! .hgtags Changeset: bf14ed159fb0 Author: kvn Date: 2012-05-23 12:11 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bf14ed159fb0 7158801: Improve VM CompileOnly option Summary: Fixed buffer overflow during parsing flags -XX:CompileCommand=, -XX:CompileOnly= and command lines in .hotspot_compiler file. Reviewed-by: never ! src/share/vm/compiler/compilerOracle.cpp Changeset: fe4a4ea5bed9 Author: kamg Date: 2012-06-08 12:49 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/fe4a4ea5bed9 7158804: Improve config file parsing Summary: Check buffer length when reading Reviewed-by: dholmes, dcubed ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp + test/runtime/7158804/Test7158804.sh Changeset: 6b5a3d18fe0e Author: asaha Date: 2012-08-02 14:29 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6b5a3d18fe0e Merge ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 000352e00389 Author: asaha Date: 2012-08-02 22:23 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/000352e00389 Merge Changeset: defeb6dad7d5 Author: asaha Date: 2012-08-10 10:41 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/defeb6dad7d5 Merge Changeset: e4d10261499c Author: asaha Date: 2012-09-07 18:18 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e4d10261499c Merge - agent/src/share/classes/sun/jvm/hotspot/code/RicochetBlob.java - agent/src/share/classes/sun/jvm/hotspot/runtime/sparc/SPARCRicochetFrame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/x86/X86RicochetFrame.java - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp - src/share/vm/gc_implementation/parNew/parGCAllocBuffer.hpp - src/share/vm/prims/methodHandleWalk.cpp - src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 521c82b9cbf8 Author: kvn Date: 2012-09-19 13:58 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/521c82b9cbf8 7198606: Improve VM optimization Summary: Remove incorrect code in OptimizeFill optimization. Reviewed-by: roland, twisti ! src/share/vm/opto/loopTransform.cpp Changeset: 849cf0480cb9 Author: asaha Date: 2012-09-25 11:47 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/849cf0480cb9 Merge Changeset: 5a3a6dac85e2 Author: asaha Date: 2012-09-26 09:54 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5a3a6dac85e2 7199488: [TEST] runtime/7158800/InternTest.java failed due to false-positive on PID match. Reviewed-by: coleenp - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: 218a94758fe7 Author: asaha Date: 2012-10-10 14:28 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/218a94758fe7 Merge - agent/make/ClosureFinder.java - agent/src/share/classes/sun/jvm/hotspot/TestDebugger.java - agent/src/share/classes/sun/jvm/hotspot/asm/AbstractInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/Address.java - agent/src/share/classes/sun/jvm/hotspot/asm/Arithmetic.java - agent/src/share/classes/sun/jvm/hotspot/asm/ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/BaseIndexScaleDispAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/CPUHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Immediate.java - agent/src/share/classes/sun/jvm/hotspot/asm/IndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLDataTypes.java - agent/src/share/classes/sun/jvm/hotspot/asm/RTLOperations.java - agent/src/share/classes/sun/jvm/hotspot/asm/ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/StoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/amd64/AMD64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/ia64/IA64Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/CoprocessorDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FP2RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FPopDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/FlushDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/Format3ADecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IllegalInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/JmplDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/LogicDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/MemoryInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RegisterDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RestoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/RettDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCAtomicLoadStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCDisassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFP2RegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFPMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFlushInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCFormat3AInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCHelper.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCIndirectCallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCInstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCJmplInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLdstubInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCLogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCMoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCNoopInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCOpcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRestoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCRettInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSaveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSethiInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSpecialStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStbarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCSwapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCTrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCUnimpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV8Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9CasInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ConditionFlags.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9DoneInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FMOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9FlushwInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9IlltrapInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ImpdepInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVccInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MOVrInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9MembarInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PopcInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrefetchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9PrivilegedRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RdprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterBranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RestoredInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9RetryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9ReturnInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SavedInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SirInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisterInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9SpecialRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCV9WrprInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SPARCWriteInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SaveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SethiDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialLoadStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/StoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/SwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/TrapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/UnimpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V8FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLdstubDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpacePrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9AlternateSpaceSwapDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CCBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9CasDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9DoneRetryDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FMOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop1Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FPop2Decoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FloatBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9FlushwDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntRegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9IntegerBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVccDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9MOVrDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PopcDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrefetchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9PrivilegedReadWriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RdprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ReadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9RegisterBranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SavedRestoredDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9SpecialStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/V9WrprDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/sparc/WriteDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/BranchDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/CallDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ConditionalJmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPLoadDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FPStoreDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/FloatGRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/GRPDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/InstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/JmpDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/LogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/MoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/RotateDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEArithmeticDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEInstructionDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSELogicalDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEMoveDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/SSEShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/ShiftDecoder.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86BranchInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CallInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86CondJmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86DirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Disassembler.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPArithmeticInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FPStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86FloatRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86GeneralInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Helper.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86IllegalInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Instruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactory.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86InstructionFactoryImpl.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86JmpInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86LogicInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MMXRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MemoryInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveLoadInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86MoveStoreInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Opcodes.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86PCRelativeAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Register.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterDirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterIndirectAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RegisterPart.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86Registers.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86RotateInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisterAddress.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86SegmentRegisters.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86ShiftInstruction.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegister.java - agent/src/share/classes/sun/jvm/hotspot/asm/x86/X86XMMRegisters.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/gc_implementation/parallelScavenge/PSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CMSPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/CompactingPermGenGen.java - agent/src/share/classes/sun/jvm/hotspot/memory/ContigPermSpace.java - agent/src/share/classes/sun/jvm/hotspot/memory/PermGen.java - agent/src/share/classes/sun/jvm/hotspot/oops/ArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/CompiledICHolderKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/KlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodDataKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/MethodKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/ObjArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/oops/TypeArrayKlassKlass.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64CurrentFrameGuess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64Frame.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64JavaCallWrapper.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/IA64RegisterMap.java - agent/src/share/classes/sun/jvm/hotspot/runtime/ia64/cInterpreter.java - agent/src/share/classes/sun/jvm/hotspot/runtime/linux_ia64/LinuxIA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/runtime/win32_ia64/Win32IA64JavaThreadPDAccess.java - agent/src/share/classes/sun/jvm/hotspot/ui/tree/BadOopTreeNodeAdapter.java - make/solaris/makefiles/reorder_COMPILER1_amd64 - make/solaris/makefiles/reorder_COMPILER1_i486 - make/solaris/makefiles/reorder_COMPILER1_sparc - make/solaris/makefiles/reorder_COMPILER1_sparcv9 - make/solaris/makefiles/reorder_COMPILER2_amd64 - make/solaris/makefiles/reorder_COMPILER2_i486 - make/solaris/makefiles/reorder_COMPILER2_sparc - make/solaris/makefiles/reorder_COMPILER2_sparcv9 - make/solaris/makefiles/reorder_CORE_i486 - make/solaris/makefiles/reorder_CORE_sparc - make/solaris/makefiles/reorder_CORE_sparcv9 - make/solaris/makefiles/reorder_TIERED_amd64 - make/solaris/makefiles/reorder_TIERED_i486 - make/solaris/makefiles/reorder_TIERED_sparc - make/solaris/makefiles/reorder_TIERED_sparcv9 - make/solaris/reorder.sh - src/cpu/sparc/vm/dump_sparc.cpp - src/cpu/x86/vm/dump_x86_32.cpp - src/cpu/x86/vm/dump_x86_64.cpp - src/cpu/zero/vm/dump_zero.cpp - src/share/tools/ProjectCreator/DirectoryTree.java - src/share/tools/ProjectCreator/DirectoryTreeNode.java - src/share/tools/ProjectCreator/FileFormatException.java - src/share/tools/ProjectCreator/WinGammaPlatformVC6.java - src/share/vm/ci/ciArrayKlassKlass.hpp - src/share/vm/ci/ciCPCache.cpp - src/share/vm/ci/ciCPCache.hpp - src/share/vm/ci/ciInstanceKlassKlass.cpp - src/share/vm/ci/ciInstanceKlassKlass.hpp - src/share/vm/ci/ciKlassKlass.cpp - src/share/vm/ci/ciKlassKlass.hpp - src/share/vm/ci/ciMethodKlass.cpp - src/share/vm/ci/ciMethodKlass.hpp - src/share/vm/ci/ciObjArrayKlassKlass.cpp - src/share/vm/ci/ciObjArrayKlassKlass.hpp - src/share/vm/ci/ciTypeArrayKlassKlass.cpp - src/share/vm/ci/ciTypeArrayKlassKlass.hpp ! src/share/vm/compiler/compilerOracle.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/cmsPermGen.hpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.cpp - src/share/vm/gc_implementation/parallelScavenge/psPermGen.hpp - src/share/vm/memory/classify.cpp - src/share/vm/memory/classify.hpp - src/share/vm/memory/compactPermGen.hpp - src/share/vm/memory/compactingPermGenGen.cpp - src/share/vm/memory/compactingPermGenGen.hpp - src/share/vm/memory/dump.cpp - src/share/vm/memory/permGen.cpp - src/share/vm/memory/permGen.hpp - src/share/vm/memory/restore.cpp - src/share/vm/memory/serialize.cpp - src/share/vm/oops/arrayKlassKlass.cpp - src/share/vm/oops/arrayKlassKlass.hpp - src/share/vm/oops/compiledICHolderKlass.cpp - src/share/vm/oops/compiledICHolderKlass.hpp - src/share/vm/oops/compiledICHolderOop.cpp - src/share/vm/oops/compiledICHolderOop.hpp - src/share/vm/oops/constMethodKlass.cpp - src/share/vm/oops/constMethodKlass.hpp - src/share/vm/oops/constMethodOop.cpp - src/share/vm/oops/constMethodOop.hpp - src/share/vm/oops/constantPoolKlass.cpp - src/share/vm/oops/constantPoolKlass.hpp - src/share/vm/oops/constantPoolOop.cpp - src/share/vm/oops/constantPoolOop.hpp - src/share/vm/oops/cpCacheKlass.cpp - src/share/vm/oops/cpCacheKlass.hpp - src/share/vm/oops/cpCacheOop.cpp - src/share/vm/oops/cpCacheOop.hpp - src/share/vm/oops/instanceKlassKlass.cpp - src/share/vm/oops/instanceKlassKlass.hpp - src/share/vm/oops/klassKlass.cpp - src/share/vm/oops/klassKlass.hpp - src/share/vm/oops/klassOop.cpp - src/share/vm/oops/klassOop.hpp - src/share/vm/oops/methodDataKlass.cpp - src/share/vm/oops/methodDataKlass.hpp - src/share/vm/oops/methodDataOop.cpp - src/share/vm/oops/methodDataOop.hpp - src/share/vm/oops/methodKlass.cpp - src/share/vm/oops/methodKlass.hpp - src/share/vm/oops/methodOop.cpp - src/share/vm/oops/methodOop.hpp - src/share/vm/oops/objArrayKlassKlass.cpp - src/share/vm/oops/objArrayKlassKlass.hpp - src/share/vm/oops/typeArrayKlassKlass.cpp - src/share/vm/oops/typeArrayKlassKlass.hpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 6ba00f89fbe1 Author: asaha Date: 2012-10-11 15:29 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6ba00f89fbe1 Merge ! src/share/vm/runtime/arguments.cpp Changeset: d2582a08fa5d Author: asaha Date: 2012-10-18 21:58 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d2582a08fa5d Merge ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/runtime/arguments.cpp Changeset: cb829aa4c98e Author: lana Date: 2012-10-25 20:07 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/cb829aa4c98e Merge - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: acabb5c282f5 Author: lana Date: 2012-10-30 13:56 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/acabb5c282f5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 4d37eb50b9b1 Author: katleman Date: 2012-11-01 14:11 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4d37eb50b9b1 Added tag jdk8-b63 for changeset acabb5c282f5 ! .hgtags Changeset: a516debe2cee Author: amurillo Date: 2012-10-26 14:18 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a516debe2cee 8001663: new hotspot build - hs25-b08 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 5ec0c42da025 Author: coleenp Date: 2012-10-25 16:33 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5ec0c42da025 7188234: Deprecate VM command line options Summary: Remove support for the UseVectoredExceptions flag Reviewed-by: jcoomes, kamg Contributed-by: harold.seigel at oracle.com ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/globals_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/globals_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/linux_zero/vm/globals_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: e81fbc04a942 Author: coleenp Date: 2012-10-25 16:33 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e81fbc04a942 7191817: -XX:+UseSerialGC -XX:+UseLargePages crashes with SIGFPE on MacOS X Summary: Disable -XX:+UseLargePages for MacOS X Reviewed-by: dholmes, coleenp, sla Contributed-by: harold.seigel at oracle.com ! src/share/vm/runtime/arguments.cpp Changeset: 0af5da0c9d9d Author: sla Date: 2012-10-29 21:04 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0af5da0c9d9d 8001619: Remove usage of _ALLBSD_SOURCE in bsd files Reviewed-by: coleenp, dholmes ! src/os/bsd/vm/attachListener_bsd.cpp ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/os_bsd.hpp ! src/os_cpu/bsd_x86/vm/bytes_bsd_x86.inline.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp Changeset: 39556eae08af Author: sspitsyn Date: 2012-10-29 11:35 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/39556eae08af 6533010: SPEC: A few broken links in jvmti.html Summary: Fix the incorrect links in jvmti.html reported by the LinkCheck tool Reviewed-by: jjh, dholmes Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnvBase.hpp Changeset: 845129b692f6 Author: minqi Date: 2012-10-29 16:39 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/845129b692f6 Merge Changeset: a1b8cf9cf970 Author: sla Date: 2012-11-01 13:05 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a1b8cf9cf970 8002078: hs_err_pid file should report full JDK version string Reviewed-by: dholmes, sspitsyn, kmo ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/vmError.cpp Changeset: cae17c597196 Author: coleenp Date: 2012-11-01 11:57 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/cae17c597196 Merge ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/globals.hpp Changeset: 3fadc0e8cffe Author: jmasa Date: 2012-10-30 10:23 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3fadc0e8cffe 8000988: VM deadlock when running btree006 on windows-i586 Reviewed-by: johnc, jcoomes, ysr ! src/share/vm/memory/collectorPolicy.cpp Changeset: 3dfffc8b9722 Author: brutisso Date: 2012-10-30 20:26 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3dfffc8b9722 8001564: The load balancing function steal_1_random in taskqueue is not random Summary: Removes the two unused functions GenericTaskQueueSet::steal_1_random and GenericTaskQueueSet::steal_best_of_all Reviewed-by: brutisso, stefank Contributed-by: erik.x.helin at oracle.com ! src/share/vm/utilities/taskqueue.hpp Changeset: ca6d147ed881 Author: jcoomes Date: 2012-11-01 23:08 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ca6d147ed881 Merge Changeset: a3e2f723f2a5 Author: twisti Date: 2012-10-29 11:08 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a3e2f723f2a5 8000780: make Zero build and run with JDK8 Reviewed-by: coleenp, dholmes, twisti Contributed-by: Roman Kennke ! make/Makefile ! src/cpu/zero/vm/cppInterpreterGenerator_zero.hpp ! src/cpu/zero/vm/cppInterpreter_zero.cpp ! src/cpu/zero/vm/cppInterpreter_zero.hpp ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/icBuffer_zero.cpp ! src/cpu/zero/vm/methodHandles_zero.cpp ! src/cpu/zero/vm/methodHandles_zero.hpp ! src/cpu/zero/vm/register_zero.hpp ! src/cpu/zero/vm/relocInfo_zero.cpp ! src/cpu/zero/vm/sharedRuntime_zero.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/cppInterpreter.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/macros.hpp Changeset: d8f9034920f6 Author: amurillo Date: 2012-11-02 04:06 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d8f9034920f6 Merge Changeset: 8cb93eadfb6d Author: amurillo Date: 2012-11-02 07:35 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8cb93eadfb6d Merge ! src/share/vm/runtime/arguments.cpp Changeset: 5920f72e799c Author: amurillo Date: 2012-11-02 07:35 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5920f72e799c Added tag hs25-b08 for changeset 8cb93eadfb6d ! .hgtags Changeset: 49bc14aaadcc Author: katleman Date: 2012-11-08 11:51 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/49bc14aaadcc Added tag jdk8-b64 for changeset 5920f72e799c ! .hgtags Changeset: ca8168203393 Author: amurillo Date: 2012-11-02 07:44 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ca8168203393 8002181: new hotspot build - hs25-b09 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 857f3ce858dd Author: dholmes Date: 2012-11-05 19:33 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/857f3ce858dd 8002034: Allow Full Debug Symbols when cross-compiling 8001756: Hotspot makefiles report missing OBJCOPY command in the wrong circumstances Reviewed-by: dcubed, dsamersoff, erikj, collins ! make/linux/makefiles/defs.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/defs.make ! make/windows/makefiles/defs.make Changeset: 3d701c802d01 Author: minqi Date: 2012-11-02 13:30 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3d701c802d01 8000489: older builds of hsdis don't work anymore after 6879063 Summary: The old function not defined properly, need a definition for export in dll. Also changes made to let new jvm work with old hsdis. Reviewed-by: jrose, sspitsyn, kmo Contributed-by: yumin.qi at oracle.com ! src/share/tools/hsdis/hsdis-demo.c ! src/share/tools/hsdis/hsdis.c ! src/share/tools/hsdis/hsdis.h ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp Changeset: 4735d2c84362 Author: kamg Date: 2012-10-11 12:25 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4735d2c84362 7200776: Implement default methods in interfaces Summary: Add generic type analysis and default method selection algorithms Reviewed-by: coleenp, acorn + src/share/vm/classfile/bytecodeAssembler.cpp + src/share/vm/classfile/bytecodeAssembler.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp + src/share/vm/classfile/defaultMethods.cpp + src/share/vm/classfile/defaultMethods.hpp + src/share/vm/classfile/genericSignatures.cpp + src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/utilities/growableArray.hpp + src/share/vm/utilities/pair.hpp + src/share/vm/utilities/resourceHash.hpp Changeset: ec204374e626 Author: kamg Date: 2012-11-02 16:09 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ec204374e626 Merge ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/globals.hpp - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: 9cc901118f6b Author: kamg Date: 2012-11-02 17:18 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/9cc901118f6b Merge Changeset: 69ad7823b1ca Author: zgu Date: 2012-11-05 15:30 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/69ad7823b1ca 8001591: NMT: assertion failed: assert(rec->addr() + rec->size() <= cur->base()) failed: Can not overlap in memSnapshot.cpp Summary: NMT should allow overlapping committed regions as long as they belong to the same reserved region Reviewed-by: dholmes, coleenp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memSnapshot.cpp Changeset: 8940ddc1036f Author: zgu Date: 2012-11-05 13:55 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8940ddc1036f Merge - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: c284cf4781f0 Author: rbackman Date: 2012-10-04 14:55 +0200 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c284cf4781f0 7127792: Add the ability to change an existing PeriodicTask's execution interval Summary: Enables dynamic enrollment / disenrollment from the PeriodicTasks in WatcherThread. Reviewed-by: dholmes, mgronlun ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/task.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 18fb7da42534 Author: coleenp Date: 2012-11-06 15:09 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/18fb7da42534 8000725: NPG: method_holder() and pool_holder() and pool_holder field should be InstanceKlass Summary: Change types of above methods and field to InstanceKlass and remove unneeded casts from the source files. Reviewed-by: dholmes, coleenp, zgu Contributed-by: harold.seigel at oracle.com ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.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/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.cpp ! 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/compilerOracle.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/heapDumper.cpp Changeset: ead8852dd4ef Author: coleenp Date: 2012-11-07 16:09 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ead8852dd4ef Merge Changeset: 64672b22ef05 Author: twisti Date: 2012-11-02 12:30 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/64672b22ef05 8001658: No need to pass resolved_references as argument to ConstantPoolCacheEntry::set_method_handle_common Reviewed-by: twisti Contributed-by: Bharadwaj Yadavalli ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/cpCache.hpp Changeset: dbeaeee28bc2 Author: kvn Date: 2012-11-06 09:22 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/dbeaeee28bc2 8002294: assert(VM_Version::supports_ssse3()) failed Summary: Add missing UseSSE check for AES intrinsics. Reviewed-by: roland, twisti ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: f3da5ff1514c Author: kvn Date: 2012-11-06 15:16 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f3da5ff1514c 8002069: Assert failed in C2: assert(field->edge_count() > 0) failed: sanity Summary: Added missed type check of initializing store in ConnectionGraph::find_init_values(). Reviewed-by: roland, twisti, vlivanov ! src/share/vm/opto/escape.cpp + test/compiler/8002069/Test8002069.java Changeset: a4e1bd941ded Author: neliasso Date: 2012-11-08 22:39 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a4e1bd941ded Merge ! src/share/vm/oops/cpCache.cpp Changeset: b4ee7b773144 Author: amurillo Date: 2012-11-09 08:20 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b4ee7b773144 Merge Changeset: 0f7290a03b24 Author: amurillo Date: 2012-11-09 08:20 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0f7290a03b24 Added tag hs25-b09 for changeset b4ee7b773144 ! .hgtags Changeset: 4e3e685dbc9d Author: katleman Date: 2012-11-15 15:39 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4e3e685dbc9d Added tag jdk8-b65 for changeset 0f7290a03b24 ! .hgtags Changeset: a35a1dd6cd6a Author: mduigou Date: 2012-11-20 12:21 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/a35a1dd6cd6a Merge ! .hgtags ! src/share/vm/classfile/bytecodeAssembler.cpp ! src/share/vm/classfile/bytecodeAssembler.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/defaultMethods.hpp ! src/share/vm/classfile/genericSignatures.cpp ! src/share/vm/classfile/genericSignatures.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/resourceHash.hpp - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: 3be318ecfae5 Author: amurillo Date: 2012-11-09 08:36 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3be318ecfae5 8003231: new hotspot build - hs25-b10 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 6cb0d32b828b Author: bpittore Date: 2012-11-07 17:53 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6cb0d32b828b 8001185: parsing of sun.boot.library.path in os::dll_build_name somewhat broken Summary: dll_dir can contain multiple paths, need to parse them correctly when loading agents Reviewed-by: dholmes, dlong Contributed-by: bill.pittore at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp Changeset: d9a84e246cce Author: cjplummer Date: 2012-11-09 09:45 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d9a84e246cce Merge ! src/share/vm/runtime/thread.cpp Changeset: 429994fc0754 Author: cjplummer Date: 2012-11-14 10:13 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/429994fc0754 Merge Changeset: 6bc207d87e5d Author: mgerdin Date: 2012-11-09 00:38 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6bc207d87e5d 7200229: NPG: possible performance issue exposed by closed/runtime/6559877/Test6559877.java Summary: Reduce the amount of calls to ChunkManager verification code Reviewed-by: jmasa, coleenp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp Changeset: 0400886d2613 Author: coleenp Date: 2012-11-14 22:37 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/0400886d2613 8003259: NPG: Build with gcc 4.7.2 broken by 7045397 Summary: Qualify calls with this pointers to make gcc accept this code. Reviewed-by: coleenp, andrew Contributed-by: peter.levart at gmail.com ! src/share/vm/memory/binaryTreeDictionary.cpp Changeset: c5d4acbb943d Author: johnc Date: 2012-11-15 14:29 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c5d4acbb943d Merge Changeset: bd7a7ce2e264 Author: minqi Date: 2012-11-12 14:03 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bd7a7ce2e264 6830717: replay of compilations would help with debugging Summary: When java process crashed in compiler thread, repeat the compilation process will help finding root cause. This is done with using SA dump application class data and replay data from core dump, then use debug version of jvm to recompile the problematic java method. Reviewed-by: kvn, twisti, sspitsyn Contributed-by: yumin.qi at oracle.com + agent/doc/c2replay.html ! agent/doc/clhsdb.html ! agent/doc/index.html ! agent/make/Makefile ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciBaseObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciConstant.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciEnv.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethod.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMethodData.java ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java ! agent/src/share/classes/sun/jvm/hotspot/compiler/CompileTask.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Field.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Metadata.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/MethodData.java ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciInstanceKlass.hpp ! src/share/vm/ci/ciMetadata.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodData.cpp ! src/share/vm/ci/ciMethodData.hpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.hpp + src/share/vm/ci/ciReplay.cpp + src/share/vm/ci/ciReplay.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp ! src/share/vm/ci/ciUtilities.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/invocationCounter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/symbol.cpp ! src/share/vm/oops/symbol.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/runtime/compilationPolicy.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/array.hpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! src/share/vm/utilities/vmError.cpp Changeset: bb33c6fdcf0d Author: bharadwaj Date: 2012-11-15 10:42 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bb33c6fdcf0d 8001077: remove ciMethod::will_link Summary: Removed will_link and changed all calls to is_loaded(). Reviewed-by: kvn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/opto/doCall.cpp Changeset: 6b6ddf8c4329 Author: neliasso Date: 2012-11-16 09:59 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6b6ddf8c4329 Merge Changeset: 64812523d72e Author: sspitsyn Date: 2012-10-31 16:20 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/64812523d72e 7194607: VerifyLocalVariableTableOnRetransformTest.sh fails after JSR-292 merge Summary: Use verifier_max_size instead of max_size to get code attribute max stack size. Reviewed-by: dcubed, minqi Contributed-by: serguei.spitsyn at oracle.com ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp Changeset: 8aaef2cee3b2 Author: minqi Date: 2012-11-08 16:48 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8aaef2cee3b2 Merge ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp - test/runtime/7158800/BadUtf8.java - test/runtime/7158800/InternTest.java - test/runtime/7158800/Test7158800.sh - test/runtime/7158800/badstrings.txt Changeset: ed8b1e39ff4f Author: zgu Date: 2012-11-09 11:04 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ed8b1e39ff4f 8002273: NMT to report JNI memory leaks when -Xcheck:jni is on Summary: Allows NMT to report that JNI thread failed to detach from JVM before exiting, which leaks the JavaThread object when check:jni option is on. Reviewed-by: acorn, dholmes, coleenp, ctornqvi ! src/share/vm/services/memSnapshot.cpp Changeset: 4efcd79826f2 Author: zgu Date: 2012-11-09 11:47 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/4efcd79826f2 Merge Changeset: fb3190e77d3c Author: zgu Date: 2012-11-09 19:24 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/fb3190e77d3c 8001592: NMT: assertion failed: assert(_amount >= amt) failed: Just check: memBaseline.hpp:180 Summary: Fixed NMT that miscounted arena memory when it is used as value or stack object. Reviewed-by: acorn, coleenp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memPtr.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTracker.hpp Changeset: e26ce0e8b666 Author: zgu Date: 2012-11-09 16:45 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e26ce0e8b666 Merge Changeset: 8c413497f434 Author: zgu Date: 2012-11-09 22:22 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/8c413497f434 Merge ! src/share/vm/services/memSnapshot.cpp Changeset: e4f764ddb06a Author: hseigel Date: 2012-11-12 15:58 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e4f764ddb06a 7122219: Passed StringTableSize value not verified Summary: Check that the values specified for -XX:StringTableSize are within a certain range. Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 070d523b96a7 Author: hseigel Date: 2012-11-12 16:15 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/070d523b96a7 8001471: Klass::cast() does nothing Summary: Remove function Klass::cast() and calls to it. Reviewed-by: dholmes, coleenp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciType.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlass.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTrace.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/biasedLocking.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/services/classLoadingService.hpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/serviceUtil.hpp Changeset: 24e193d2a007 Author: coleenp Date: 2012-11-13 15:14 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/24e193d2a007 Merge Changeset: 80e866b1d053 Author: coleenp Date: 2012-11-16 09:19 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/80e866b1d053 Merge ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/cpCache.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/thread.cpp Changeset: cfc5309f03b7 Author: amurillo Date: 2012-11-16 09:36 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/cfc5309f03b7 Merge Changeset: 01684f7fee1b Author: amurillo Date: 2012-11-16 09:36 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/01684f7fee1b Added tag hs25-b10 for changeset cfc5309f03b7 ! .hgtags Changeset: 2f6dc76eb8e5 Author: katleman Date: 2012-11-29 11:30 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2f6dc76eb8e5 Added tag jdk8-b66 for changeset 01684f7fee1b ! .hgtags Changeset: 1b8d9f645aac Author: mduigou Date: 2012-12-04 11:45 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/1b8d9f645aac Merge ! .hgtags ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/reflection.cpp From mike.duigou at oracle.com Tue Dec 4 12:21:55 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 04 Dec 2012 20:21:55 +0000 Subject: hg: lambda/lambda/jdk: 36 new changesets Message-ID: <20121204203123.908A047DB8@hg.openjdk.java.net> Changeset: 03d22c98b30a Author: ceisserer Date: 2012-11-13 16:12 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/03d22c98b30a 7105461: Large JTables are not rendered correctly with Xrender pipeline Reviewed-by: flar, prr ! src/solaris/classes/sun/java2d/xr/XRRenderer.java ! src/solaris/classes/sun/java2d/xr/XRUtils.java Changeset: ed977ca9a969 Author: lana Date: 2012-11-20 11:46 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ed977ca9a969 Merge Changeset: 11ba8795bbe9 Author: kshefov Date: 2012-11-14 11:37 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/11ba8795bbe9 7147408: [macosx] Add autodelay to fix a regression test Reviewed-by: serb, alexsch + test/javax/swing/text/StyledEditorKit/4506788/bug4506788.html + test/javax/swing/text/StyledEditorKit/4506788/bug4506788.java Changeset: f32a0aee7bb9 Author: alitvinov Date: 2012-11-14 18:40 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f32a0aee7bb9 6789984: JPasswordField can not receive keyboard input Reviewed-by: naoto, anthony ! src/share/classes/sun/awt/im/InputContext.java ! src/share/classes/sun/awt/im/InputMethodAdapter.java ! src/solaris/classes/sun/awt/X11InputMethod.java Changeset: 0269459afe2a Author: malenkov Date: 2012-11-20 18:56 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0269459afe2a 8003333: Regression: java/beans/EventHandler/Test6277266.java fails with ACE Reviewed-by: art ! test/java/beans/EventHandler/Test6277266.java Changeset: ea368459cca5 Author: lana Date: 2012-11-20 11:47 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ea368459cca5 Merge Changeset: c3e7ceb22d37 Author: alanb Date: 2012-11-11 10:05 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c3e7ceb22d37 8003253: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Unbounded.java hang intermittently [win] Reviewed-by: chegar ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java Changeset: 5d3f8f9e6c58 Author: okutsu Date: 2012-11-12 11:12 +0900 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5d3f8f9e6c58 8000986: Split java.util.spi.CalendarDataProvider into week parameters and field names portions Reviewed-by: naoto ! make/java/java/FILES_java.gmk ! src/macosx/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/spi/CalendarDataProvider.java + src/share/classes/java/util/spi/CalendarNameProvider.java ! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java + src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! src/windows/classes/sun/util/locale/provider/HostLocaleProviderAdapterImpl.java ! test/java/util/PluggableLocale/CalendarDataProviderTest.java ! test/java/util/PluggableLocale/CalendarDataProviderTest.sh + test/java/util/PluggableLocale/CalendarNameProviderTest.java + test/java/util/PluggableLocale/CalendarNameProviderTest.sh ! test/java/util/PluggableLocale/GenericTest.java ! test/java/util/PluggableLocale/barprovider.jar ! test/java/util/PluggableLocale/fooprovider.jar ! test/java/util/PluggableLocale/providersrc/CalendarDataProviderImpl.java + test/java/util/PluggableLocale/providersrc/CalendarNameProviderImpl.java ! test/java/util/PluggableLocale/providersrc/Makefile + test/java/util/PluggableLocale/providersrc/java.util.spi.CalendarNameProvider Changeset: be1fb42ef696 Author: mduigou Date: 2012-11-13 20:02 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/be1fb42ef696 7088913: Add compatible static hashCode(primitive) to primitive wrapper classes Summary: Adds static utility methods to each primitive wrapper class to allow calculation of a hashCode value from an unboxed primitive. Reviewed-by: darcy, smarks, dholmes ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java ! test/java/lang/HashCode.java Changeset: 83765e82cacb Author: zhouyx Date: 2012-11-14 13:26 +0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/83765e82cacb 7201156: jar tool fails to convert file separation characters for list and extract Reviewed-by: alanb, chegar, sherman ! src/share/classes/sun/tools/jar/Main.java + test/tools/jar/JarBackSlash.java Changeset: 0f54a98f9bc9 Author: alanb Date: 2012-11-14 12:56 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0f54a98f9bc9 8003285: TEST_BUG: java/nio/channels/AsynchronousChannelGroup/Unbounded.java fails again [macosx] Reviewed-by: chegar ! test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java Changeset: 369709a13823 Author: jjg Date: 2012-11-14 07:08 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/369709a13823 8000404: rename javax.tools.GenerateNativeHeader to java.lang.annotation.Native Reviewed-by: alanb + src/share/classes/java/lang/annotation/Native.java Changeset: e24123de581c Author: mduigou Date: 2012-11-13 20:02 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e24123de581c 7088952: Add size in bytes constant "BYTES" to primitive type wrapper types Summary: Adds a constant BYTES to each of the primitive wrapper classes (Byte, Character, Double, Float, Integer, Long, Short) with the calculation Primitive.SIZE / Byte.SIZE already made. Reviewed-by: dholmes ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java Changeset: f4de6a38f794 Author: lana Date: 2012-11-14 16:41 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f4de6a38f794 Merge Changeset: ac22a52a732c Author: jgish Date: 2012-11-15 13:46 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ac22a52a732c 6244047: impossible to specify directories to logging FileHandler unless they exist Reviewed-by: alanb ! src/share/classes/java/util/logging/FileHandler.java + test/java/util/logging/CheckLockLocationTest.java Changeset: 51c695958712 Author: weijun Date: 2012-11-16 10:34 +0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/51c695958712 8003263: redundant cast build failure after 8003120 Reviewed-by: alanb ! src/share/classes/com/sun/naming/internal/ResourceManager.java Changeset: 64a42798ea5e Author: naoto Date: 2012-11-15 20:17 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/64a42798ea5e 7199750: Loading sequence of service provider is changed Reviewed-by: okutsu ! src/share/classes/sun/util/locale/provider/SPILocaleProviderAdapter.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.sh ! test/java/util/PluggableLocale/barprovider.jar ! test/java/util/PluggableLocale/providersrc/CurrencyNameProviderImpl2.java Changeset: 0ee09f17361e Author: khazra Date: 2012-11-16 12:28 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0ee09f17361e 8003518: (prefs) Tests in jdk/test/java/util/prefs should not be run concurrently Summary: Add java/util/prefs to exclusiveAccess.dirs in TEST.ROOT Reviewed-by: alanb, mchung ! test/TEST.ROOT Changeset: 6f20caa6e1e9 Author: bchristi Date: 2012-11-16 17:01 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6f20caa6e1e9 7178922: (props) re-visit how os.name is determined on Mac Reviewed-by: alanb, mchung, skovatch, serb ! src/solaris/native/java/lang/java_props_macosx.c Changeset: 25e5df117021 Author: xuelei Date: 2012-11-18 01:31 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/25e5df117021 8003587: Warning cleanup in package javax.net.ssl Summary: Removes unnecessary imports and adds missing Override annotations Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/javax/net/ssl/HandshakeCompletedEvent.java ! src/share/classes/javax/net/ssl/HostnameVerifier.java ! src/share/classes/javax/net/ssl/HttpsURLConnection.java ! src/share/classes/javax/net/ssl/KeyManagerFactory.java ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/net/ssl/SSLContextSpi.java ! src/share/classes/javax/net/ssl/SSLEngineResult.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLPermission.java ! src/share/classes/javax/net/ssl/SSLServerSocketFactory.java ! src/share/classes/javax/net/ssl/SSLSession.java ! src/share/classes/javax/net/ssl/SSLSocket.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java ! src/share/classes/javax/net/ssl/TrustManagerFactory.java ! src/share/classes/javax/net/ssl/X509KeyManager.java Changeset: f740a9ac6eb6 Author: weijun Date: 2012-11-19 11:13 +0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f740a9ac6eb6 8002344: Krb5LoginModule config class does not return proper KDC list from DNS Reviewed-by: weijun Contributed-by: Severin Gehwolf , Wang Weijun ! src/share/classes/sun/security/krb5/Config.java + test/sun/security/krb5/config/DNS.java + test/sun/security/krb5/config/NamingManager.java + test/sun/security/krb5/config/dns.sh Changeset: 3877706701b1 Author: alanb Date: 2012-11-19 13:17 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3877706701b1 8003607: More ProblemList.txt updates (11/2012) Reviewed-by: lancea ! test/ProblemList.txt ! test/TEST.ROOT Changeset: 2d08b404cd91 Author: jzavgren Date: 2012-11-20 09:26 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2d08b404cd91 8000476: Memory Leaks and uninitialized memory access in PKCS11 and other native code Reviewed-by: dsamersoff, valeriep, chegar ! src/share/bin/wildcard.c ! src/share/native/sun/security/jgss/wrapper/GSSLibStub.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/solaris/bin/java_md_solinux.c Changeset: 914cd9b482c8 Author: ksrini Date: 2012-11-19 19:49 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/914cd9b482c8 8001533: java launcher must launch javafx applications Reviewed-by: ksrini, mchung, kcr, alanb Contributed-by: david.dehaven at oracle.com ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! test/tools/launcher/TestHelper.java Changeset: b1c364c84d09 Author: ksrini Date: 2012-11-19 19:50 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b1c364c84d09 8003660: (launcher) 8001533 regression tests Reviewed-by: ksrini, mchung, kcr, ddehaven Contributed-by: steve.sides at oracle.com + test/tools/launcher/FXLauncherTest.java Changeset: 107a7a52a3c0 Author: lana Date: 2012-11-20 11:49 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/107a7a52a3c0 Merge Changeset: ccff3b663797 Author: tbell Date: 2012-11-14 10:21 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ccff3b663797 8001906: build-infra: warning: [path] bad path element on Solaris Summary: Remove unnecesary -cp parameter from compile line Reviewed-by: ohair, tbell Contributed-by: erik.joelsson at oracle.com ! makefiles/CompileDemos.gmk Changeset: 716efc201640 Author: tbell Date: 2012-11-15 00:55 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/716efc201640 Merge Changeset: 44e845bb5f76 Author: erikj Date: 2012-11-28 09:47 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/44e845bb5f76 8003960: build-infra: Jarsigner launcher has wrong classname Summary: Fixed package name in launcher Reviewed-by: alanb, ohair, ohrstrom ! makefiles/CompileLaunchers.gmk Changeset: ad5741112252 Author: erikj Date: 2012-11-28 13:20 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ad5741112252 8001460: build-infra: Linker warnings on macosx Summary: Remove creation of empty i386 section from fdlibm Reviewed-by: ohair ! makefiles/CompileNativeLibraries.gmk Changeset: 7ecc80d2ff2e Author: erikj Date: 2012-11-28 13:29 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7ecc80d2ff2e 8003477: build-infra: Remove explicit source file listings for libs when possible Reviewed-by: ohair, ohrstrom ! makefiles/CompileNativeLibraries.gmk Changeset: 51d2fd6d9850 Author: erikj Date: 2012-11-28 13:49 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/51d2fd6d9850 8003528: build-infra: Diffs in libjava and hotspot libs on solaris. Summary: Reorder libraries on link command line to match old build. Reviewed-by: ohair, ohrstrom ! makefiles/CompileNativeLibraries.gmk Changeset: 54516ed0f99f Author: erikj Date: 2012-11-28 14:10 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/54516ed0f99f 8003482: build-infra: Use correct manifest in security jars Reviewed-by: ohair, ohrstrom ! makefiles/CreateJars.gmk Changeset: 4d337fae2250 Author: katleman Date: 2012-11-28 14:06 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4d337fae2250 Merge Changeset: df5619994dc3 Author: katleman Date: 2012-11-29 11:31 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/df5619994dc3 Added tag jdk8-b66 for changeset 4d337fae2250 ! .hgtags Changeset: 054da1af4668 Author: mduigou Date: 2012-12-04 11:58 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/054da1af4668 Merge ! .hgtags ! make/java/java/FILES_java.gmk ! src/share/bin/java.c ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Byte.java ! src/share/classes/java/lang/Character.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/lang/Short.java From paul.sandoz at oracle.com Tue Dec 4 13:01:00 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 4 Dec 2012 22:01:00 +0100 Subject: First element of a parallel stream? +possible bug report In-Reply-To: <50BE0346.4020909@oracle.com> References: <50BE0346.4020909@oracle.com> Message-ID: <9181478E-06BD-4F12-B1CC-FF55D899DD13@oracle.com> On Dec 4, 2012, at 3:05 PM, Dmitry Bessonov wrote: > 1)Question: > > Is the result of the following chain of operations defined > and should be the same on all hardware/implementations? > > Arrays.asList("first", "second", "last").parallel().findFirst(); > Yes, it will return the same result as for stream().findFirst(). > > 2) Report: Slightly modified version throws NPE > (with the yesterday's state of the repo) : > > Arrays.asList("first", "second", null, "last").parallel().findFirst(); > Right, Optional is totally null intolerant at the moment. Paul. From paul.sandoz at oracle.com Tue Dec 4 13:10:38 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 4 Dec 2012 22:10:38 +0100 Subject: Stream.cumulate issue In-Reply-To: <50BE159D.4090506@oracle.com> References: <50BE159D.4090506@oracle.com> Message-ID: Hi, Thanks for reporting. It's another one of those null tolerence bugs. I know what's causing it, null is used to mean no result, as there are cases when the leaf nodes has no values to process. Paul. On Dec 4, 2012, at 4:24 PM, Georgiy Rakov wrote: > Hello, > > cumulate().toArray() seems not to work properly with nulls. Consider following code: > > import java.util.Arrays; > import java.util.stream.Stream; > > public class CumulateIssue { > public static void main(String [] argv) { > Stream stream = Arrays.parallel(new Object[]{null, > null, null, null}).cumulate((a, b)->3); > System.out.println(Arrays.toString(stream.toArray())); > } > } > > > It obviously should output: > > [null, 3, 3, 3] > > But instead it outputs: > > [null, null, null, null] > > I could suppose it's a bug. Please confirm if it is. > > I use nightly build of November 5. > > The code is attached for your convenience. > > Thanks, > Georgiy. > From mike.duigou at oracle.com Tue Dec 4 13:17:06 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 04 Dec 2012 21:17:06 +0000 Subject: hg: lambda/lambda/jdk: javadoc and naming cleanups Message-ID: <20121204211727.99BF147DB9@hg.openjdk.java.net> Changeset: 67493b08922f Author: akhil Date: 2012-12-04 13:16 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/67493b08922f javadoc and naming cleanups ! src/share/classes/java/lang/ThreadLocal.java From mike.duigou at oracle.com Tue Dec 4 13:26:39 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 04 Dec 2012 21:26:39 +0000 Subject: hg: lambda/lambda/jdk: Remove test of non-existant removeAll(Predicate). Message-ID: <20121204212650.5DAB847DBC@hg.openjdk.java.net> Changeset: 97b5f15b4545 Author: mduigou Date: 2012-12-04 13:26 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/97b5f15b4545 Remove test of non-existant removeAll(Predicate). ! test/java/util/Collection/MOAT.java From dmitry.bessonov at oracle.com Tue Dec 4 13:43:58 2012 From: dmitry.bessonov at oracle.com (Dmitry Bessonov) Date: Wed, 05 Dec 2012 01:43:58 +0400 Subject: First element of a parallel stream? +possible bug report In-Reply-To: <9181478E-06BD-4F12-B1CC-FF55D899DD13@oracle.com> References: <50BE0346.4020909@oracle.com> <9181478E-06BD-4F12-B1CC-FF55D899DD13@oracle.com> Message-ID: <50BE6E9E.5030903@oracle.com> On 05.12.2012 1:01, Paul Sandoz wrote: > On Dec 4, 2012, at 3:05 PM, Dmitry Bessonov wrote: > >> 1)Question: >> >> Is the result of the following chain of operations defined >> and should be the same on all hardware/implementations? >> >> Arrays.asList("first", "second", "last").parallel().findFirst(); >> > Yes, it will return the same result as for stream().findFirst(). > > >> 2) Report: Slightly modified version throws NPE >> (with the yesterday's state of the repo) : >> >> Arrays.asList("first", "second", null, "last").parallel().findFirst(); >> > Right, Optional is totally null intolerant at the moment. I know that it's about the parallel() implementation but if the result is strictly defined - always the first element then not tolerating the third 'null' really looks like a bug no matter if Optional accepts nulls or not... -Dmitry From mike.duigou at oracle.com Tue Dec 4 14:31:01 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 04 Dec 2012 22:31:01 +0000 Subject: hg: lambda/lambda/hotspot: #ifndef PRODUCT on some debug code Message-ID: <20121204223105.8FA4947DCD@hg.openjdk.java.net> Changeset: c2309a6de8d2 Author: mduigou Date: 2012-12-04 14:30 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c2309a6de8d2 #ifndef PRODUCT on some debug code ! src/share/vm/classfile/defaultMethods.cpp From mike.duigou at oracle.com Tue Dec 4 15:34:39 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 4 Dec 2012 15:34:39 -0800 Subject: Updated lambda binary drop (b67) Message-ID: Hello Lambdoozlers; After some unfortunate delays related to the Thanksgiving US holiday the lambda binary drop on java.net has been updated. http://jdk8.java.net/lambda/ Enjoy! From mike.duigou at oracle.com Tue Dec 4 21:20:47 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 05 Dec 2012 05:20:47 +0000 Subject: hg: lambda/lambda/jdk: javadoc improvements suggested by 8004015 review Message-ID: <20121205052110.9D0E947DF6@hg.openjdk.java.net> Changeset: 378e1a955ffe Author: mduigou Date: 2012-12-04 21:20 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/378e1a955ffe javadoc improvements suggested by 8004015 review ! src/share/classes/java/util/function/BiBlock.java ! src/share/classes/java/util/function/BiFunction.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Combiner.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/FlatMapper.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/Functions.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/function/Predicates.java ! src/share/classes/java/util/function/UnaryOperator.java From mike.duigou at oracle.com Tue Dec 4 21:47:20 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 4 Dec 2012 21:47:20 -0800 Subject: Request for Review : CR#8004015 : [2nd pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: References: Message-ID: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> Hello all; I have updated the proposed patch. The changes primarily add class and method documentation regarding handling of null for the primitive specializations. http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/ http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html I've also reformatted the source for the default methods. Mike On Nov 26 2012, at 18:12 , Mike Duigou wrote: > Hello all; > > In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. > > Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. > > The patch to add parent interfaces and default methods can be found here: > > http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ > http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html > > Mike > > [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697 From david.holmes at oracle.com Tue Dec 4 22:10:30 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 05 Dec 2012 16:10:30 +1000 Subject: Request for Review : CR#8004015 : [2nd pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> Message-ID: <50BEE556.6090602@oracle.com> Hi Mike, In multiple places: + *

xxx ... Should that be

tag? Is it actually needed? (my javadoc is a bit rusty). Aside: I don't realise you could {@inheritDoc) as a simple text insertion mechanism. Just to be clear, the null-handling statements are intended to be normative and apply to anyone who might provide an implementation of theses classes - right? Thanks, David On 5/12/2012 3:47 PM, Mike Duigou wrote: > Hello all; > > I have updated the proposed patch. The changes primarily add class and method documentation regarding handling of null for the primitive specializations. > > http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/ > http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html > > I've also reformatted the source for the default methods. > > Mike > > > On Nov 26 2012, at 18:12 , Mike Duigou wrote: > >> Hello all; >> >> In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. >> >> Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. >> >> The patch to add parent interfaces and default methods can be found here: >> >> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ >> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html >> >> Mike >> >> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697 > From pbenedict at apache.org Tue Dec 4 22:16:25 2012 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 5 Dec 2012 00:16:25 -0600 Subject: hg: lambda/lambda/jdk: javadoc improvements suggested by 8004015 review In-Reply-To: <20121205052110.9D0E947DF6@hg.openjdk.java.net> References: <20121205052110.9D0E947DF6@hg.openjdk.java.net> Message-ID: Mike, There are several places where there's an extra space between "public" and "default" -- just a note for some misc clean up next time around. For example: public default T combine(T t1, T t2) Paul On Tue, Dec 4, 2012 at 11:20 PM, wrote: > Changeset: 378e1a955ffe > Author: mduigou > Date: 2012-12-04 21:20 -0800 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/378e1a955ffe > > javadoc improvements suggested by 8004015 review > > ! src/share/classes/java/util/function/BiBlock.java > ! src/share/classes/java/util/function/BiFunction.java > ! src/share/classes/java/util/function/BinaryOperator.java > ! src/share/classes/java/util/function/Combiner.java > ! src/share/classes/java/util/function/DoubleBinaryOperator.java > ! src/share/classes/java/util/function/DoubleBlock.java > ! src/share/classes/java/util/function/DoubleFunction.java > ! src/share/classes/java/util/function/DoubleSupplier.java > ! src/share/classes/java/util/function/DoubleUnaryOperator.java > ! src/share/classes/java/util/function/FlatMapper.java > ! src/share/classes/java/util/function/Function.java > ! src/share/classes/java/util/function/Functions.java > ! src/share/classes/java/util/function/IntBinaryOperator.java > ! src/share/classes/java/util/function/IntBlock.java > ! src/share/classes/java/util/function/IntFunction.java > ! src/share/classes/java/util/function/IntSupplier.java > ! src/share/classes/java/util/function/IntUnaryOperator.java > ! src/share/classes/java/util/function/LongBinaryOperator.java > ! src/share/classes/java/util/function/LongBlock.java > ! src/share/classes/java/util/function/LongFunction.java > ! src/share/classes/java/util/function/LongSupplier.java > ! src/share/classes/java/util/function/LongUnaryOperator.java > ! src/share/classes/java/util/function/Predicates.java > ! src/share/classes/java/util/function/UnaryOperator.java > > From jonathan.gibbons at oracle.com Tue Dec 4 23:00:43 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 04 Dec 2012 23:00:43 -0800 Subject: Request for Review : CR#8004015 : [2nd pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: <50BEE556.6090602@oracle.com> References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> <50BEE556.6090602@oracle.com> Message-ID: <50BEF11B.2090008@oracle.com> To be clear,

is not legal HTML (although browsers may accept it), and the upcoming doclint will report a syntax error. -- Jon On 12/04/2012 10:10 PM, David Holmes wrote: > Hi Mike, > > In multiple places: > > + *

xxx ... > > Should that be

tag? Is it actually needed? (my javadoc is a bit rusty). > > Aside: I don't realise you could {@inheritDoc) as a simple text > insertion mechanism. > > Just to be clear, the null-handling statements are intended to be > normative and apply to anyone who might provide an implementation of > theses classes - right? > > Thanks, > David > > On 5/12/2012 3:47 PM, Mike Duigou wrote: >> Hello all; >> >> I have updated the proposed patch. The changes primarily add class and method documentation regarding handling of null for the primitive specializations. >> >> http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/ >> http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html >> >> I've also reformatted the source for the default methods. >> >> Mike >> >> >> On Nov 26 2012, at 18:12 , Mike Duigou wrote: >> >>> Hello all; >>> >>> In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. >>> >>> Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. >>> >>> The patch to add parent interfaces and default methods can be found here: >>> >>> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ >>> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html >>> >>> Mike >>> >>> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697 From paul.sandoz at oracle.com Wed Dec 5 00:36:14 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 5 Dec 2012 09:36:14 +0100 Subject: First element of a parallel stream? +possible bug report In-Reply-To: <50BE6E9E.5030903@oracle.com> References: <50BE0346.4020909@oracle.com> <9181478E-06BD-4F12-B1CC-FF55D899DD13@oracle.com> <50BE6E9E.5030903@oracle.com> Message-ID: <8FB791FD-DAB2-4313-A9B1-BE5BA7612204@oracle.com> On Dec 4, 2012, at 10:43 PM, Dmitry Bessonov wrote: > On 05.12.2012 1:01, Paul Sandoz wrote: >> On Dec 4, 2012, at 3:05 PM, Dmitry Bessonov wrote: >> >>> 1)Question: >>> >>> Is the result of the following chain of operations defined >>> and should be the same on all hardware/implementations? >>> >>> Arrays.asList("first", "second", "last").parallel().findFirst(); >>> >> Yes, it will return the same result as for stream().findFirst(). >> >> >>> 2) Report: Slightly modified version throws NPE >>> (with the yesterday's state of the repo) : >>> >>> Arrays.asList("first", "second", null, "last").parallel().findFirst(); >>> >> Right, Optional is totally null intolerant at the moment. > > > I know that it's about the parallel() implementation > but if the result is strictly defined - always the first element > then not tolerating the third 'null' > really looks like a bug no matter if Optional accepts nulls or not... > I agree it's a bug, one that is non-deterministic. That could also happen for findAny as well. The find op is too aggressive creating Optional instances, only one optional instance should be created after the root task has completed. Paul. From forax at univ-mlv.fr Wed Dec 5 00:46:09 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 05 Dec 2012 09:46:09 +0100 Subject: hg: lambda/lambda/jdk: - ensure null values are retained In-Reply-To: References: <20121203160019.42F8947CE6@hg.openjdk.java.net> <50BDB360.1000100@univ-mlv.fr> <49B6AEF6-6D22-46AB-90BF-F8B86B2E210F@oracle.com> <50BDF9EB.20101@univ-mlv.fr> Message-ID: <50BF09D1.3060106@univ-mlv.fr> On 12/04/2012 02:53 PM, Paul Sandoz wrote: > On Dec 4, 2012, at 2:26 PM, Remi Forax wrote: > >> On 12/04/2012 11:44 AM, Paul Sandoz wrote: >>> Hi Remi, >>> >>> Many thanks, that is just the kind of VM-perspective advice i was looking for. I was assuming that the VM would be able to somehow inline the hot path to the else block. >> yes, but you don't need a supplementary field for that. >> > Right, but subjectively i think it is marginally clearer code. > > >>> So you are suggesting something like this: >>> >>> T _t = (T) maskNull(t); >>> if (lastSeen == null || !lastSeen.equals(_t)) { >>> lastSeen = _t; >>> downstream.accept(t); >>> } >> I was thinking to something like this: >> >> return new Sink.ChainedReference(sink) { >> private Object lastSeen; >> >> @Override >> public void begin(long size) { >> lastSeen = null; // not needed if end() is called in a finally ? > It's not needed. > > >> downstream.begin(-1); >> } >> >> @Override >> public void end() { >> lastSeen = null; >> downstream.end(); >> } >> >> @Override >> public void accept(T t) { >> if (t == null) { >> if (lastSeen != NULL_OBJECT) { >> lastSeen = NULL_OBJECT >> downstream.accept(null); >> } >> } else if (lastSeen == null || !t.equals(lastSeen)) { >> lastSeen = t; >> downstream.accept((T)t); >> } >> } >> }; >> > If one assumes nulls are rare is there any performance advantage (beyond the extra field not being used) to using the null object design pattern in this context? Not for this code, but remember that I've sent the mail for the whole patch. I believe that that an holistic approach should be used in all ops, because all ops need to deal with null. > > I am trying and failing to correlate what you say below with the code base: > > "Your solution require to load/store value from the RAM because the VM will not able to optimize this code (inlining is often defeated due to the fact that the call between ops is a virtual call)." I've written this sentence when I've read the last lines of your patch, the one that use an AtomicInteger because you can't store null in a CHM. Masking null in that case avoid multiple accesses to the RAM. > > Paul. R?mi From paul.sandoz at oracle.com Wed Dec 5 01:40:44 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 5 Dec 2012 10:40:44 +0100 Subject: The build is still failing on my Mac Message-ID: <30BF8805-445E-4A19-A71D-E9847E7ACFCF@oracle.com> Hi, Same problem still exists for me. The jdk/makefiles/Setup.gmk has been modified on lambda and is out of sync with tl. http://www.diffnow.com/?report=pqmwi jdk8 $ diff lambda/jdk/makefiles/Setup.gmk tl/jdk/makefiles/Setup.gmk 30c30 < DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-auxiliaryclass --- > DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally I presume that others are using a version of JDK 8 for a Boot JDK rather than a version JDK 7? Paul. From paul.sandoz at oracle.com Wed Dec 5 01:43:54 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 5 Dec 2012 10:43:54 +0100 Subject: hg: lambda/lambda/jdk: - ensure null values are retained In-Reply-To: <50BF09D1.3060106@univ-mlv.fr> References: <20121203160019.42F8947CE6@hg.openjdk.java.net> <50BDB360.1000100@univ-mlv.fr> <49B6AEF6-6D22-46AB-90BF-F8B86B2E210F@oracle.com> <50BDF9EB.20101@univ-mlv.fr> <50BF09D1.3060106@univ-mlv.fr> Message-ID: On Dec 5, 2012, at 9:46 AM, Remi Forax wrote: > On 12/04/2012 02:53 PM, Paul Sandoz wrote: >> On Dec 4, 2012, at 2:26 PM, Remi Forax wrote: >> >>> On 12/04/2012 11:44 AM, Paul Sandoz wrote: >>>> Hi Remi, >>>> >>>> Many thanks, that is just the kind of VM-perspective advice i was looking for. I was assuming that the VM would be able to somehow inline the hot path to the else block. >>> yes, but you don't need a supplementary field for that. >>> >> Right, but subjectively i think it is marginally clearer code. >> >> >>>> So you are suggesting something like this: >>>> >>>> T _t = (T) maskNull(t); >>>> if (lastSeen == null || !lastSeen.equals(_t)) { >>>> lastSeen = _t; >>>> downstream.accept(t); >>>> } >>> I was thinking to something like this: >>> >>> return new Sink.ChainedReference(sink) { >>> private Object lastSeen; >>> >>> @Override >>> public void begin(long size) { >>> lastSeen = null; // not needed if end() is called in a finally ? >> It's not needed. >> >> >>> downstream.begin(-1); >>> } >>> >>> @Override >>> public void end() { >>> lastSeen = null; >>> downstream.end(); >>> } >>> >>> @Override >>> public void accept(T t) { >>> if (t == null) { >>> if (lastSeen != NULL_OBJECT) { >>> lastSeen = NULL_OBJECT >>> downstream.accept(null); >>> } >>> } else if (lastSeen == null || !t.equals(lastSeen)) { >>> lastSeen = t; >>> downstream.accept((T)t); >>> } >>> } >>> }; >>> >> If one assumes nulls are rare is there any performance advantage (beyond the extra field not being used) to using the null object design pattern in this context? > > Not for this code, but remember that I've sent the mail for the whole patch. I realize that :-) just confused on the context of some of your comments. > I believe that that an holistic approach should be used in all ops, > because all ops need to deal with null. > Agreed. I think a little helper class may be in order to avoid peppering static final Object NULL/NONE = new Object() and mask methods all over the place. >> >> I am trying and failing to correlate what you say below with the code base: >> >> "Your solution require to load/store value from the RAM because the VM will not able to optimize this code (inlining is often defeated due to the fact that the call between ops is a virtual call)." > > I've written this sentence when I've read the last lines of your patch, > the one that use an AtomicInteger because you can't store null in a CHM. > Masking null in that case avoid multiple accesses to the RAM. > Thanks, Paul. From paul.sandoz at oracle.com Wed Dec 5 01:44:46 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 5 Dec 2012 10:44:46 +0100 Subject: hg: lambda/lambda/jdk: - ensure null values are retained In-Reply-To: <50BE04C5.5070001@univ-mlv.fr> References: <20121203160019.42F8947CE6@hg.openjdk.java.net> <50BDB360.1000100@univ-mlv.fr> <49B6AEF6-6D22-46AB-90BF-F8B86B2E210F@oracle.com> <50BDF9EB.20101@univ-mlv.fr> <50BE01EB.1060407@gmail.com> <50BE04C5.5070001@univ-mlv.fr> Message-ID: On Dec 4, 2012, at 3:12 PM, Remi Forax wrote: > On 12/04/2012 03:00 PM, Peter Levart wrote: >> Hi Remi, Paul, >> >> What about vice-versa: > > Hi Peter, > good idea ! +1 Paul. > we still need a if (t==null) in accept() and not use Objects.equals > because we want the VM to profile the null in accept() and not in > Objects.equals(). > > R?mi > >> >> Like this: >> >> private static final Object NONE = new Object(); >> ... >> >> return new Sink.ChainedReference(sink) { >> private Object lastSeen; >> >> @Override >> public void begin(long size) { >> lastSeen = NONE; // not needed if end() is >> called in a finally ? >> downstream.begin(-1); >> } >> >> @Override >> public void end() { >> lastSeen = NONE; >> downstream.end(); >> } >> >> @Override >> public void accept(T t) { >> if (!Objects.equals(t, lastSeen)) { >> lastSeen = t; >> downstream.accept(t); >> } >> } >> }; From paul.sandoz at oracle.com Wed Dec 5 02:08:02 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 05 Dec 2012 10:08:02 +0000 Subject: hg: lambda/lambda/jdk: - unify Find operations. Message-ID: <20121205100824.7311747E1C@hg.openjdk.java.net> Changeset: ce5cc90de176 Author: psandoz Date: 2012-12-05 11:07 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ce5cc90de176 - unify Find operations. - test if first result is the first present - test if any result is present (Note the level of indirection to the next elements can be removed once logging warnings go away, since we are just moving around where the boxing hit occurs) ! src/share/classes/java/util/stream/ReferencePipeline.java - src/share/classes/java/util/stream/op/FindAnyOp.java - src/share/classes/java/util/stream/op/FindFirstOp.java + src/share/classes/java/util/stream/op/FindOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! test-ng/tests/org/openjdk/tests/java/util/stream/SpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindAnyOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindFirstOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java From scolebourne at joda.org Wed Dec 5 03:00:20 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 11:00:20 +0000 Subject: Request for Review : CR#8004015 : [2nd pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> Message-ID: On 5 December 2012 05:47, Mike Duigou wrote: > Hello all; > > I have updated the proposed patch. The changes primarily add class and method documentation regarding handling of null for the primitive specializations. > > http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/ > http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html > > I've also reformatted the source for the default methods. The extra null comments and formatting look good. I do note that the suppliers do not have the extra null comments. Stephen From scolebourne at joda.org Wed Dec 5 03:05:15 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 11:05:15 +0000 Subject: Request for Review : CR#8004015 : [2nd pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: <50BEF11B.2090008@oracle.com> References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> <50BEE556.6090602@oracle.com> <50BEF11B.2090008@oracle.com> Message-ID: On 5 December 2012 07:00, Jonathan Gibbons wrote: > To be clear,

is not legal HTML (although browsers may accept it), > and the upcoming doclint will report a syntax error. FWIW I wrote up some Javadoc coding guidelines recently. (I use

between paras) http://blog.joda.org/2012/11/javadoc-coding-standards.html Stephen From Lance.Andersen at oracle.com Wed Dec 5 03:49:42 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 5 Dec 2012 06:49:42 -0500 Subject: Request for Review : CR#8004015 : [2nd pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> Message-ID: <965DB95B-8F79-4025-B4D9-94C5CCF12403@oracle.com> I am still wondering if we need some sort of javadoc tag for default implementations so that it will stand out better and allow us to be consistent with how we specify this across Java SE and other APIs that leverage default methods. Has any thought been given to this? Best Lance On Dec 5, 2012, at 12:47 AM, Mike Duigou wrote: > Hello all; > > I have updated the proposed patch. The changes primarily add class and method documentation regarding handling of null for the primitive specializations. > > http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/ > http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html > > I've also reformatted the source for the default methods. > > Mike > > > On Nov 26 2012, at 18:12 , Mike Duigou wrote: > >> Hello all; >> >> In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. >> >> Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. >> >> The patch to add parent interfaces and default methods can be found here: >> >> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ >> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html >> >> Mike >> >> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697 > -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From forax at univ-mlv.fr Wed Dec 5 04:25:46 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 05 Dec 2012 13:25:46 +0100 Subject: hg: lambda/lambda/jdk: - ensure null values are retained In-Reply-To: References: <20121203160019.42F8947CE6@hg.openjdk.java.net> <50BDB360.1000100@univ-mlv.fr> <49B6AEF6-6D22-46AB-90BF-F8B86B2E210F@oracle.com> <50BDF9EB.20101@univ-mlv.fr> <50BE01EB.1060407@gmail.com> <50BE04C5.5070001@univ-mlv.fr> Message-ID: <50BF3D4A.4040308@univ-mlv.fr> On 12/05/2012 10:44 AM, Paul Sandoz wrote: > On Dec 4, 2012, at 3:12 PM, Remi Forax wrote: > >> On 12/04/2012 03:00 PM, Peter Levart wrote: >>> Hi Remi, Paul, >>> >>> What about vice-versa: >> Hi Peter, >> good idea ! > +1 yes, I think two constants are needed, one is NO_VALUE and is used as init value to detect that an element is the first one because queries like findFirst or reduce does something different for the first element and null is a valid first element. The other is NULL_VALUE and is used only in the parallel code to mask null because concurrent collections doesn't support null but parallel stream supports null. > > Paul. R?mi From bharadwaj.yadavalli at oracle.com Wed Dec 5 08:20:45 2012 From: bharadwaj.yadavalli at oracle.com (Bharadwaj Yadavalli) Date: Wed, 05 Dec 2012 11:20:45 -0500 Subject: The build is still failing on my Mac In-Reply-To: <30BF8805-445E-4A19-A71D-E9847E7ACFCF@oracle.com> References: <30BF8805-445E-4A19-A71D-E9847E7ACFCF@oracle.com> Message-ID: <50BF745D.9060000@oracle.com> I get the same build failure on Mac OS 10.7.5 when using 7u9 as boot JDK. I was able to build (albeit with a TON of warnings about bitness incompatibility and compiler incompatibility) if I get rid of -auxiliaryclass from the -Xlint options. I do not yet know if the bits that were built are any good. 1. I am using the command 'make NEWBUILD=true all' - which I believe uses new build infrastructure. Is this what is supported? * Should I be using old build instead? 2. Should I build and use JDK 8 as boot JDK? Thanks for any help and suggestions, Bharadwaj On 12/5/2012 4:40 AM, Paul Sandoz wrote: > Hi, > > Same problem still exists for me. > > The jdk/makefiles/Setup.gmk has been modified on lambda and is out of sync with tl. > > http://www.diffnow.com/?report=pqmwi > > jdk8 $ diff lambda/jdk/makefiles/Setup.gmk tl/jdk/makefiles/Setup.gmk > 30c30 > < DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-auxiliaryclass > --- >> DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally > I presume that others are using a version of JDK 8 for a Boot JDK rather than a version JDK 7? > > Paul. > > > From paul.sandoz at oracle.com Wed Dec 5 08:47:35 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 05 Dec 2012 16:47:35 +0000 Subject: hg: lambda/lambda/jdk: - unify match op for reference and int streams Message-ID: <20121205164819.5021147E3E@hg.openjdk.java.net> Changeset: 4c81036aeadc Author: psandoz Date: 2012-12-05 17:47 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4c81036aeadc - unify match op for reference and int streams ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/op/MatchOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MatchOpTest.java From mike.duigou at oracle.com Wed Dec 5 10:07:54 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 5 Dec 2012 10:07:54 -0800 Subject: Request for Review : CR#8004015 : [2nd pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: <50BEE556.6090602@oracle.com> References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> <50BEE556.6090602@oracle.com> Message-ID: <56B46C81-9364-4329-B373-80D1D80B295A@oracle.com> On Dec 4 2012, at 22:10 , David Holmes wrote: > Hi Mike, > > In multiple places: > > + *

xxx ... > > Should that be

tag? Is it actually needed? (my javadoc is a bit rusty). Many of these were added/changed by NetBeans styler. I then added additional instances. I have converted all of the

->

. I have also filed a bug against NetBans styler: http://netbeans.org/bugzilla/show_bug.cgi?id=223342 > Aside: I don't realise you could {@inheritDoc) as a simple text insertion mechanism. I only learned of this in the last six months myself. :-) > Just to be clear, the null-handling statements are intended to be normative and apply to anyone who might provide an implementation of theses classes - right? Correct. I would prefer that they were not but it seems unavoidable. Mike > > Thanks, > David > > On 5/12/2012 3:47 PM, Mike Duigou wrote: >> Hello all; >> >> I have updated the proposed patch. The changes primarily add class and method documentation regarding handling of null for the primitive specializations. >> >> http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/ >> http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html >> >> I've also reformatted the source for the default methods. >> >> Mike >> >> >> On Nov 26 2012, at 18:12 , Mike Duigou wrote: >> >>> Hello all; >>> >>> In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. >>> >>> Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. >>> >>> The patch to add parent interfaces and default methods can be found here: >>> >>> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ >>> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html >>> >>> Mike >>> >>> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697 >> From mike.duigou at oracle.com Wed Dec 5 10:15:59 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 5 Dec 2012 10:15:59 -0800 Subject: Request for Review : CR#8004015 : [2nd pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> Message-ID: On Dec 5 2012, at 03:00 , Stephen Colebourne wrote: > On 5 December 2012 05:47, Mike Duigou wrote: >> Hello all; >> >> I have updated the proposed patch. The changes primarily add class and method documentation regarding handling of null for the primitive specializations. >> >> http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/ >> http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html >> >> I've also reformatted the source for the default methods. > > The extra null comments and formatting look good. I do note that the > suppliers do not have the extra null comments. Since supplier takes no params I hoped to avoid having to make a statement about null. Since specifying that null will never be returned actually simplifies things I opted to add the constraint. Mike From c.mallwitz at gmail.com Wed Dec 5 10:18:46 2012 From: c.mallwitz at gmail.com (Christian Mallwitz) Date: Wed, 5 Dec 2012 18:18:46 +0000 Subject: StreamOpFlag.* and OutOfMemoryError when going parall Message-ID: Hi, Using lambda-8-b67-linux-i586-03_dec_2012 I'm trying to compute n (not necessarily the first n) prime numbers: import java.util.*; import java.util.function.*; import java.util.stream.*; public class LambdaExample3 { public static boolean isPrime(long n) { if (n <= 1) { return false; } if (n == 2) { return true; } for (int i = 2; i <= Math.sqrt(n) + 1; i++) { if (n % i == 0) return false; } return true; } public static void main(String[] args) { Stream stream = Streams.parallel(Streams.spliteratorUnknownSize(new Iterator() { private long n = 0; @Override public boolean hasNext() { return true; } @Override public Long next() { return ++n; } }), // fails with OutOfMemoryError // StreamOpFlag.toStreamFlags(StreamOpFlag.NOT_SIZED, StreamOpFlag.INITIAL_OPS_VALUE) // fails with OutOfMemoryError // StreamOpFlag.NOT_SIZED // works, but no speed-up to non-parallel version StreamOpFlag.INITIAL_OPS_VALUE ); stream .filter(LambdaExample3::isPrime) .limit(300000) .forEach(l -> { /*System.out.println(l);*/ }); } } I'm struggling with the StreamOpFlag parameter. What should I pick? INITIAL_OPS_VALUE seems to work but isn't running anything in parallel (at least it is not faster than the serial version). NOT_SIZED isn't working but failing miserably with an OutOfMemoryError. IS_PARALLEL is not needed because I already use parallel() - should specifying IS_PARALLEL and using Streams.stream() supposed to go parallel as well? Is the OutOfMemoryError caused by a bug? The OutOfMemoryError is reported from a fork/join pool thread so at least it is going parallel? Am I missing something? Thanks Christian From mike.duigou at oracle.com Wed Dec 5 10:20:26 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 5 Dec 2012 10:20:26 -0800 Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> Message-ID: I have updated webrev again to fix some reported javadoc technical issues and added null handling specification to the {Int|Double|Long}Supplier. http://cr.openjdk.java.net/~mduigou/8004015/2/webrev/ http://cr.openjdk.java.net/~mduigou/8004015/2/specdiff/java/util/function/package-summary.html I believe that this iteration is complete (or very nearly so). Mike On Dec 4 2012, at 21:47 , Mike Duigou wrote: > Hello all; > > I have updated the proposed patch. The changes primarily add class and method documentation regarding handling of null for the primitive specializations. > > http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/ > http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html > > I've also reformatted the source for the default methods. > > Mike > > > On Nov 26 2012, at 18:12 , Mike Duigou wrote: > >> Hello all; >> >> In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. >> >> Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. >> >> The patch to add parent interfaces and default methods can be found here: >> >> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ >> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html >> >> Mike >> >> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697 > From brian.goetz at oracle.com Wed Dec 5 10:34:15 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 05 Dec 2012 13:34:15 -0500 Subject: StreamOpFlag.* and OutOfMemoryError when going parall In-Reply-To: References: Message-ID: <50BF93A7.8000400@oracle.com> There's a good reason you are struggling with it -- this API is not intended for "casual" builders of streams. The intention is that 99.9% of users will never write code to call the Streams.stream() method directly; they will use arrays, collections, generators, or other packaged providers of streams. A safe default is 0. You can OR together the IS_ version of the flags if you know something about the nature of your stream. You probably want IS_ORDERED if you want to represent a stream for which the order of elements means something (e.g., a range generator, a List, an array, etc.) The reason it is failing with OOME is that the parallel implementation of limit() computes the entire results rather than operating fully lazily. While it would be preferable to operate more lazily, a lazy parallel implementation of operations like limit is not trivial. We hope to improve this in the future. On 12/5/2012 1:18 PM, Christian Mallwitz wrote: > Hi, > > Using lambda-8-b67-linux-i586-03_dec_2012 I'm trying to compute n (not > necessarily the first n) prime numbers: > > import java.util.*; > import java.util.function.*; > import java.util.stream.*; > > public class LambdaExample3 { > > public static boolean isPrime(long n) { > if (n <= 1) { return false; } > if (n == 2) { return true; } > for (int i = 2; i <= Math.sqrt(n) + 1; i++) { if (n % i == 0) > return false; } > return true; > } > > public static void main(String[] args) { > > Stream stream = > Streams.parallel(Streams.spliteratorUnknownSize(new Iterator() { > private long n = 0; > @Override public boolean hasNext() { return true; } > @Override public Long next() { return ++n; } > }), > // fails with OutOfMemoryError > // StreamOpFlag.toStreamFlags(StreamOpFlag.NOT_SIZED, > StreamOpFlag.INITIAL_OPS_VALUE) > // fails with OutOfMemoryError > // StreamOpFlag.NOT_SIZED > // works, but no speed-up to non-parallel version > StreamOpFlag.INITIAL_OPS_VALUE > ); > > stream > .filter(LambdaExample3::isPrime) > .limit(300000) > .forEach(l -> { /*System.out.println(l);*/ }); > } > } > > I'm struggling with the StreamOpFlag parameter. What should I pick? > INITIAL_OPS_VALUE seems to work but isn't running anything in parallel > (at least it is not faster than the serial version). NOT_SIZED isn't > working but failing miserably with an OutOfMemoryError. IS_PARALLEL > is not needed because I already use parallel() - should specifying > IS_PARALLEL and using Streams.stream() supposed to go parallel as > well? > > Is the OutOfMemoryError caused by a bug? The OutOfMemoryError is > reported from a fork/join pool thread so at least it is going > parallel? Am I missing something? > > Thanks > Christian > From forax at univ-mlv.fr Wed Dec 5 10:41:47 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 05 Dec 2012 19:41:47 +0100 Subject: StreamOpFlag.* and OutOfMemoryError when going parall In-Reply-To: References: Message-ID: <50BF956B.3010705@univ-mlv.fr> On 12/05/2012 07:18 PM, Christian Mallwitz wrote: > Hi, > > Using lambda-8-b67-linux-i586-03_dec_2012 I'm trying to compute n (not > necessarily the first n) prime numbers: > > import java.util.*; > import java.util.function.*; > import java.util.stream.*; > > public class LambdaExample3 { > > public static boolean isPrime(long n) { > if (n <= 1) { return false; } > if (n == 2) { return true; } > for (int i = 2; i <= Math.sqrt(n) + 1; i++) { if (n % i == 0) > return false; } > return true; > } > > public static void main(String[] args) { > > Stream stream = > Streams.parallel(Streams.spliteratorUnknownSize(new Iterator() { > private long n = 0; > @Override public boolean hasNext() { return true; } > @Override public Long next() { return ++n; } > }), > // fails with OutOfMemoryError > // StreamOpFlag.toStreamFlags(StreamOpFlag.NOT_SIZED, > StreamOpFlag.INITIAL_OPS_VALUE) > // fails with OutOfMemoryError > // StreamOpFlag.NOT_SIZED > // works, but no speed-up to non-parallel version > StreamOpFlag.INITIAL_OPS_VALUE > ); > > stream > .filter(LambdaExample3::isPrime) > .limit(300000) > .forEach(l -> { /*System.out.println(l);*/ }); > } > } > > I'm struggling with the StreamOpFlag parameter. What should I pick? > INITIAL_OPS_VALUE seems to work but isn't running anything in parallel > (at least it is not faster than the serial version). NOT_SIZED isn't > working but failing miserably with an OutOfMemoryError. IS_PARALLEL > is not needed because I already use parallel() - should specifying > IS_PARALLEL and using Streams.stream() supposed to go parallel as > well? > > Is the OutOfMemoryError caused by a bug? The OutOfMemoryError is > reported from a fork/join pool thread so at least it is going > parallel? Am I missing something? I've trouble to understand how you expect that your code work in parallel. > > Thanks > Christian > R?mi From c.mallwitz at gmail.com Wed Dec 5 10:54:21 2012 From: c.mallwitz at gmail.com (Christian Mallwitz) Date: Wed, 5 Dec 2012 18:54:21 +0000 Subject: StreamOpFlag.* and OutOfMemoryError when going parall In-Reply-To: <50BF93A7.8000400@oracle.com> References: <50BF93A7.8000400@oracle.com> Message-ID: Very well :-) Leaving the parallel aspect aside, If I just wanted to find the first n prime numbers based on a possibly infinity stream of numbers (I don't want to use a Collection with a known size), is there another 'officially' approved way to covert an Iterator to a Stream (instead of using Streams.stream())? Regarding a fully lazy, parallel limit() and its future: does 'future' mean pre- or post-JDK8? Cheers! Christian On Wed, Dec 5, 2012 at 6:34 PM, Brian Goetz wrote: > There's a good reason you are struggling with it -- this API is not intended > for "casual" builders of streams. The intention is that 99.9% of users will > never write code to call the Streams.stream() method directly; they will use > arrays, collections, generators, or other packaged providers of streams. > > A safe default is 0. You can OR together the IS_ version of the flags if > you know something about the nature of your stream. You probably want > IS_ORDERED if you want to represent a stream for which the order of elements > means something (e.g., a range generator, a List, an array, etc.) > > The reason it is failing with OOME is that the parallel implementation of > limit() computes the entire results rather than operating fully lazily. > While it would be preferable to operate more lazily, a lazy parallel > implementation of operations like limit is not trivial. We hope to improve > this in the future. > > On 12/5/2012 1:18 PM, Christian Mallwitz wrote: >> >> Hi, >> >> Using lambda-8-b67-linux-i586-03_dec_2012 I'm trying to compute n (not >> necessarily the first n) prime numbers: >> >> import java.util.*; >> import java.util.function.*; >> import java.util.stream.*; >> >> public class LambdaExample3 { >> >> public static boolean isPrime(long n) { >> if (n <= 1) { return false; } >> if (n == 2) { return true; } >> for (int i = 2; i <= Math.sqrt(n) + 1; i++) { if (n % i == 0) >> return false; } >> return true; >> } >> >> public static void main(String[] args) { >> >> Stream stream = >> Streams.parallel(Streams.spliteratorUnknownSize(new Iterator() { >> private long n = 0; >> @Override public boolean hasNext() { return true; } >> @Override public Long next() { return ++n; } >> }), >> // fails with OutOfMemoryError >> // StreamOpFlag.toStreamFlags(StreamOpFlag.NOT_SIZED, >> StreamOpFlag.INITIAL_OPS_VALUE) >> // fails with OutOfMemoryError >> // StreamOpFlag.NOT_SIZED >> // works, but no speed-up to non-parallel version >> StreamOpFlag.INITIAL_OPS_VALUE >> ); >> >> stream >> .filter(LambdaExample3::isPrime) >> .limit(300000) >> .forEach(l -> { /*System.out.println(l);*/ }); >> } >> } >> >> I'm struggling with the StreamOpFlag parameter. What should I pick? >> INITIAL_OPS_VALUE seems to work but isn't running anything in parallel >> (at least it is not faster than the serial version). NOT_SIZED isn't >> working but failing miserably with an OutOfMemoryError. IS_PARALLEL >> is not needed because I already use parallel() - should specifying >> IS_PARALLEL and using Streams.stream() supposed to go parallel as >> well? >> >> Is the OutOfMemoryError caused by a bug? The OutOfMemoryError is >> reported from a fork/join pool thread so at least it is going >> parallel? Am I missing something? >> >> Thanks >> Christian >> > From brian.goetz at oracle.com Wed Dec 5 11:07:51 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 05 Dec 2012 14:07:51 -0500 Subject: StreamOpFlag.* and OutOfMemoryError when going parall In-Reply-To: References: <50BF93A7.8000400@oracle.com> Message-ID: <50BF9B87.50908@oracle.com> It is quite likely that "limit" is just not a sharp enough tool here. The intent of skip+limit was to handle things like pagination -- "give me results 20-30". We're working on something that should handle cancelation more generally, to support cases like "find the best answer you can in 5m", that might be a better choice. Stay tuned. As to the timing, we make no promises :) On 12/5/2012 1:54 PM, Christian Mallwitz wrote: > Very well :-) > > Leaving the parallel aspect aside, If I just wanted to find the first > n prime numbers based on a possibly infinity stream of numbers (I > don't want to use a Collection with a known size), is there another > 'officially' approved way to covert an Iterator to a Stream (instead > of using Streams.stream())? > > Regarding a fully lazy, parallel limit() and its future: does 'future' > mean pre- or post-JDK8? > > Cheers! > Christian > > On Wed, Dec 5, 2012 at 6:34 PM, Brian Goetz wrote: >> There's a good reason you are struggling with it -- this API is not intended >> for "casual" builders of streams. The intention is that 99.9% of users will >> never write code to call the Streams.stream() method directly; they will use >> arrays, collections, generators, or other packaged providers of streams. >> >> A safe default is 0. You can OR together the IS_ version of the flags if >> you know something about the nature of your stream. You probably want >> IS_ORDERED if you want to represent a stream for which the order of elements >> means something (e.g., a range generator, a List, an array, etc.) >> >> The reason it is failing with OOME is that the parallel implementation of >> limit() computes the entire results rather than operating fully lazily. >> While it would be preferable to operate more lazily, a lazy parallel >> implementation of operations like limit is not trivial. We hope to improve >> this in the future. >> >> On 12/5/2012 1:18 PM, Christian Mallwitz wrote: >>> >>> Hi, >>> >>> Using lambda-8-b67-linux-i586-03_dec_2012 I'm trying to compute n (not >>> necessarily the first n) prime numbers: >>> >>> import java.util.*; >>> import java.util.function.*; >>> import java.util.stream.*; >>> >>> public class LambdaExample3 { >>> >>> public static boolean isPrime(long n) { >>> if (n <= 1) { return false; } >>> if (n == 2) { return true; } >>> for (int i = 2; i <= Math.sqrt(n) + 1; i++) { if (n % i == 0) >>> return false; } >>> return true; >>> } >>> >>> public static void main(String[] args) { >>> >>> Stream stream = >>> Streams.parallel(Streams.spliteratorUnknownSize(new Iterator() { >>> private long n = 0; >>> @Override public boolean hasNext() { return true; } >>> @Override public Long next() { return ++n; } >>> }), >>> // fails with OutOfMemoryError >>> // StreamOpFlag.toStreamFlags(StreamOpFlag.NOT_SIZED, >>> StreamOpFlag.INITIAL_OPS_VALUE) >>> // fails with OutOfMemoryError >>> // StreamOpFlag.NOT_SIZED >>> // works, but no speed-up to non-parallel version >>> StreamOpFlag.INITIAL_OPS_VALUE >>> ); >>> >>> stream >>> .filter(LambdaExample3::isPrime) >>> .limit(300000) >>> .forEach(l -> { /*System.out.println(l);*/ }); >>> } >>> } >>> >>> I'm struggling with the StreamOpFlag parameter. What should I pick? >>> INITIAL_OPS_VALUE seems to work but isn't running anything in parallel >>> (at least it is not faster than the serial version). NOT_SIZED isn't >>> working but failing miserably with an OutOfMemoryError. IS_PARALLEL >>> is not needed because I already use parallel() - should specifying >>> IS_PARALLEL and using Streams.stream() supposed to go parallel as >>> well? >>> >>> Is the OutOfMemoryError caused by a bug? The OutOfMemoryError is >>> reported from a fork/join pool thread so at least it is going >>> parallel? Am I missing something? >>> >>> Thanks >>> Christian >>> >> > From forax at univ-mlv.fr Wed Dec 5 11:11:41 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 05 Dec 2012 20:11:41 +0100 Subject: StreamOpFlag.* and OutOfMemoryError when going parall In-Reply-To: References: <50BF93A7.8000400@oracle.com> Message-ID: <50BF9C6D.9000008@univ-mlv.fr> On 12/05/2012 07:54 PM, Christian Mallwitz wrote: > Very well :-) > > Leaving the parallel aspect aside, If I just wanted to find the first > n prime numbers based on a possibly infinity stream of numbers (I > don't want to use a Collection with a known size), is there another > 'officially' approved way to covert an Iterator to a Stream (instead > of using Streams.stream())? I understand what you want to do but I don't understand how you want the code to work in parallel. > > Regarding a fully lazy, parallel limit() and its future: does 'future' > mean pre- or post-JDK8? > > Cheers! > Christian regards, R?mi From mike.duigou at oracle.com Wed Dec 5 11:43:35 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 5 Dec 2012 11:43:35 -0800 Subject: The build is still failing on my Mac In-Reply-To: <30BF8805-445E-4A19-A71D-E9847E7ACFCF@oracle.com> References: <30BF8805-445E-4A19-A71D-E9847E7ACFCF@oracle.com> Message-ID: Everything compiled in jdk should be done with the langtools javac rather than the boot javac. Regardless, I am using 7u9 on MacOS and not seeing this problem so it's even weirder. If I remove the "-auxiliaryclass" then my build fails because there are indeed jdk classes with auxiliary classes. Mike On Dec 5 2012, at 01:40 , Paul Sandoz wrote: > Hi, > > Same problem still exists for me. > > The jdk/makefiles/Setup.gmk has been modified on lambda and is out of sync with tl. > > http://www.diffnow.com/?report=pqmwi > > jdk8 $ diff lambda/jdk/makefiles/Setup.gmk tl/jdk/makefiles/Setup.gmk > 30c30 > < DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-auxiliaryclass > --- >> DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally > > I presume that others are using a version of JDK 8 for a Boot JDK rather than a version JDK 7? > > Paul. > > > From mike.duigou at oracle.com Wed Dec 5 11:44:20 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 5 Dec 2012 11:44:20 -0800 Subject: The build is still failing on my Mac In-Reply-To: <50BF745D.9060000@oracle.com> References: <30BF8805-445E-4A19-A71D-E9847E7ACFCF@oracle.com> <50BF745D.9060000@oracle.com> Message-ID: <12A8C39B-F46D-485B-923C-30C719584C05@oracle.com> On Dec 5 2012, at 08:20 , Bharadwaj Yadavalli wrote: > I get the same build failure on Mac OS 10.7.5 when using 7u9 as boot JDK. > > I was able to build (albeit with a TON of warnings about bitness > incompatibility and compiler incompatibility) if I get rid of > -auxiliaryclass from the -Xlint options. I do not yet know if the bits > that were built are any good. > > 1. I am using the command 'make NEWBUILD=true all' - which I believe > uses new build infrastructure. Is this what is supported? Yes. > * Should I be using old build instead? Generally, unless you need javadoc, no. > 2. Should I build and use JDK 8 as boot JDK? Should not be necessary. > > Thanks for any help and suggestions, > > Bharadwaj > > On 12/5/2012 4:40 AM, Paul Sandoz wrote: >> Hi, >> >> Same problem still exists for me. >> >> The jdk/makefiles/Setup.gmk has been modified on lambda and is out of sync with tl. >> >> http://www.diffnow.com/?report=pqmwi >> >> jdk8 $ diff lambda/jdk/makefiles/Setup.gmk tl/jdk/makefiles/Setup.gmk >> 30c30 >> < DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-auxiliaryclass >> --- >>> DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally >> I presume that others are using a version of JDK 8 for a Boot JDK rather than a version JDK 7? >> >> Paul. >> >> >> > From paul.sandoz at oracle.com Wed Dec 5 11:52:52 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 5 Dec 2012 20:52:52 +0100 Subject: The build is still failing on my Mac In-Reply-To: References: <30BF8805-445E-4A19-A71D-E9847E7ACFCF@oracle.com> Message-ID: <2D5F5A39-DAF3-4B28-9BC9-20C04C88D5D7@oracle.com> On Dec 5, 2012, at 8:43 PM, Mike Duigou wrote: > Everything compiled in jdk should be done with the langtools javac rather than the boot javac. > > Regardless, I am using 7u9 on MacOS and not seeing this problem so it's even weirder. > Same here. My system: OS X 10.8.2, XCode 4.4.1 > If I remove the "-auxiliaryclass" then my build fails because there are indeed jdk classes with auxiliary classes. > How come the tl/jdk repo does not require "-auxiliaryclass" ? Cab you build tl? It's the opposite for me, i cannot build with that flag. What error do you get? Paul. > Mike > > > On Dec 5 2012, at 01:40 , Paul Sandoz wrote: > >> Hi, >> >> Same problem still exists for me. >> >> The jdk/makefiles/Setup.gmk has been modified on lambda and is out of sync with tl. >> >> http://www.diffnow.com/?report=pqmwi >> >> jdk8 $ diff lambda/jdk/makefiles/Setup.gmk tl/jdk/makefiles/Setup.gmk >> 30c30 >> < DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-auxiliaryclass >> --- >>> DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally >> >> I presume that others are using a version of JDK 8 for a Boot JDK rather than a version JDK 7? >> >> Paul. >> >> >> > From mike.duigou at oracle.com Wed Dec 5 12:12:36 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 05 Dec 2012 20:12:36 +0000 Subject: hg: lambda/lambda/jdk: cleanups and formatting Message-ID: <20121205201306.2D33D47E61@hg.openjdk.java.net> Changeset: 20fe1f76516d Author: mduigou Date: 2012-12-05 09:42 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/20fe1f76516d cleanups and formatting ! src/share/classes/java/util/function/BiBlock.java ! src/share/classes/java/util/function/BiFunction.java ! src/share/classes/java/util/function/BiPredicate.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Combiner.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/FlatMapper.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/function/Predicates.java ! src/share/classes/java/util/function/UnaryOperator.java From akhil.arora at oracle.com Wed Dec 5 13:27:37 2012 From: akhil.arora at oracle.com (Akhil Arora) Date: Wed, 05 Dec 2012 13:27:37 -0800 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50BC0576.4070202@oracle.com> References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com> Message-ID: <50BFBC49.9020200@oracle.com> Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/ - delegate to Math.min/max for int/long/float/double - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor - removed Character variants of min/max/sum On 12/02/2012 05:50 PM, David Holmes wrote: > Hi Akhil, > > Is it really necessary/desirable to flag all of these as " Suitable for > conversion as a method reference to functional interfaces such as ..." ? Not necessary, but it does provide a hint as to their intended use to a casual browser of these docs. > This style: > > + * @param a a boolean argument. > + * @param b another boolean argument. > > is at odds with the style used elsewhere for new Functional APIs, and > with the style of other methods in these classes. Can we just use "first > operand" and "second operand" for all of these? It is consistent with Math.min/max, which use the a/b style. Since these methods are not in one of the functional package, is'nt it better to stick to the local style? > Character.sum does not make sense to me. Who adds together characters? > I'm not even sure min and max are worth supporting for Character. Good point - removed these methods for Character. > I disagree with other suggestions to use the Math functions for > float/double. I think all these methods should use the underlying > primitive operator regardless of type. Are you disagreeing only for float/double or for int/long also? Can you provide more information as to why you disagree? Thanks > Thanks, > David > ----- > > On 1/12/2012 4:44 AM, Akhil Arora wrote: >> Hi >> >> Requesting review for some basic functionality related to lambdas - >> >> Add min, max, sum methods to the primitive wrapper classes - Byte, >> Short, Integer, Long, Float, Double and Character so as to be able to >> use them as reducers in lambda expressions. Add and, or, xor methods to >> Boolean. >> >> http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201 >> >> Thanks From vitalyd at gmail.com Wed Dec 5 13:42:01 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 5 Dec 2012 16:42:01 -0500 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50BFBC49.9020200@oracle.com> References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com> <50BFBC49.9020200@oracle.com> Message-ID: Regarding Character methods; it's unorthodox but some people use them as "fake" unsigned shorts. Whether that's enough to justify adding sum/max/min, I don't know. Sent from my phone On Dec 5, 2012 4:28 PM, "Akhil Arora" wrote: > Updated - http://cr.openjdk.java.net/~**akhil/8004201.1/webrev/ > > - delegate to Math.min/max for int/long/float/double > - rename Boolean.and/or/xor to logicalAnd/logicalOr/**logicalXor > - removed Character variants of min/max/sum > > On 12/02/2012 05:50 PM, David Holmes wrote: > >> Hi Akhil, >> >> Is it really necessary/desirable to flag all of these as " Suitable for >> conversion as a method reference to functional interfaces such as ..." ? >> > > Not necessary, but it does provide a hint as to their intended use to a > casual browser of these docs. > > This style: >> >> + * @param a a boolean argument. >> + * @param b another boolean argument. >> >> is at odds with the style used elsewhere for new Functional APIs, and >> with the style of other methods in these classes. Can we just use "first >> operand" and "second operand" for all of these? >> > > It is consistent with Math.min/max, which use the a/b style. Since these > methods are not in one of the functional package, is'nt it better to stick > to the local style? > > Character.sum does not make sense to me. Who adds together characters? >> I'm not even sure min and max are worth supporting for Character. >> > > Good point - removed these methods for Character. > > I disagree with other suggestions to use the Math functions for >> float/double. I think all these methods should use the underlying >> primitive operator regardless of type. >> > > Are you disagreeing only for float/double or for int/long also? Can you > provide more information as to why you disagree? > > Thanks > > Thanks, >> David >> ----- >> >> On 1/12/2012 4:44 AM, Akhil Arora wrote: >> >>> Hi >>> >>> Requesting review for some basic functionality related to lambdas - >>> >>> Add min, max, sum methods to the primitive wrapper classes - Byte, >>> Short, Integer, Long, Float, Double and Character so as to be able to >>> use them as reducers in lambda expressions. Add and, or, xor methods to >>> Boolean. >>> >>> http://cr.openjdk.java.net/~**akhil/8004201.0/webrev/ >>> http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8004201 >>> >>> Thanks >>> >> > From mike.duigou at oracle.com Wed Dec 5 13:52:34 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 05 Dec 2012 21:52:34 +0000 Subject: hg: lambda/lambda/jdk: 8003258: BufferedReader.lines() minor fixes and adds unit test Message-ID: <20121205215247.7A42447EA5@hg.openjdk.java.net> Changeset: 4e2ccfc8378f Author: henryjen Date: 2012-12-05 13:52 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4e2ccfc8378f 8003258: BufferedReader.lines() minor fixes and adds unit test ! src/share/classes/java/io/BufferedReader.java + test/java/io/BufferedReader/Lines.java From mike.duigou at oracle.com Wed Dec 5 14:01:20 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 05 Dec 2012 22:01:20 +0000 Subject: hg: lambda/lambda/jdk: Adds thenComparing extension methods to Comparator for chaining comparators. Message-ID: <20121205220131.7C67F47EBB@hg.openjdk.java.net> Changeset: caedfd90faf7 Author: henryjen Date: 2012-12-05 14:00 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/caedfd90faf7 Adds thenComparing extension methods to Comparator for chaining comparators. ! src/share/classes/java/util/Comparator.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SortedOpTest.java ! test/java/util/ComparatorsTest.java From forax at univ-mlv.fr Wed Dec 5 14:15:54 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 05 Dec 2012 23:15:54 +0100 Subject: hg: lambda/lambda/jdk: Adds thenComparing extension methods to Comparator for chaining comparators. In-Reply-To: <20121205220131.7C67F47EBB@hg.openjdk.java.net> References: <20121205220131.7C67F47EBB@hg.openjdk.java.net> Message-ID: <50BFC79A.2060406@univ-mlv.fr> On 12/05/2012 11:01 PM, mike.duigou at oracle.com wrote: > Changeset: caedfd90faf7 > Author: henryjen > Date: 2012-12-05 14:00 -0800 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/caedfd90faf7 > > Adds thenComparing extension methods to Comparator for chaining comparators. > > ! src/share/classes/java/util/Comparator.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SortedOpTest.java > ! test/java/util/ComparatorsTest.java > > Mike, I think you should move the implementation of Comparators into Comparator and get ride of Comparators. R?mi From scolebourne at joda.org Wed Dec 5 14:26:39 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 22:26:39 +0000 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50BFBC49.9020200@oracle.com> References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com> <50BFBC49.9020200@oracle.com> Message-ID: On 5 December 2012 21:27, Akhil Arora wrote: > Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/ > > - delegate to Math.min/max for int/long/float/double > - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor Is there a case for logicalNot() ? Stephen From mike.duigou at oracle.com Wed Dec 5 14:40:08 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 5 Dec 2012 14:40:08 -0800 Subject: hg: lambda/lambda/jdk: Adds thenComparing extension methods to Comparator for chaining comparators. In-Reply-To: <50BFC79A.2060406@univ-mlv.fr> References: <20121205220131.7C67F47EBB@hg.openjdk.java.net> <50BFC79A.2060406@univ-mlv.fr> Message-ID: <6613BEF2-5D01-40FA-A69A-280C996D4963@oracle.com> This is planned to happen before the move into JDK mainline. There's still a runtime support issue for static interface methods (http://mail.openjdk.java.net/pipermail/lambda-dev/2012-December/006972.html) that's holding us back a bit. Mike On Dec 5 2012, at 14:15 , Remi Forax wrote: > On 12/05/2012 11:01 PM, mike.duigou at oracle.com wrote: >> Changeset: caedfd90faf7 >> Author: henryjen >> Date: 2012-12-05 14:00 -0800 >> URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/caedfd90faf7 >> >> Adds thenComparing extension methods to Comparator for chaining comparators. >> >> ! src/share/classes/java/util/Comparator.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SortedOpTest.java >> ! test/java/util/ComparatorsTest.java >> >> > > Mike, > I think you should move the implementation of Comparators into > Comparator and get ride of Comparators. > > R?mi > > From brian.goetz at oracle.com Wed Dec 5 14:53:48 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 05 Dec 2012 17:53:48 -0500 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com> <50BFBC49.9020200@oracle.com> Message-ID: <50BFD07C.4030002@oracle.com> Here, we're adding things that could be converted to SAMs, and logicalNot could be converted to a UnaryOperator, so, there's a case :) On 12/5/2012 5:26 PM, Stephen Colebourne wrote: > On 5 December 2012 21:27, Akhil Arora wrote: >> Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/ >> >> - delegate to Math.min/max for int/long/float/double >> - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor > > Is there a case for logicalNot() ? > > Stephen > From scolebourne at joda.org Wed Dec 5 15:02:25 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Dec 2012 23:02:25 +0000 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50BFD07C.4030002@oracle.com> References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com> <50BFBC49.9020200@oracle.com> <50BFD07C.4030002@oracle.com> Message-ID: Which would lead me to look at http://docs.oracle.com/javase/tutorial/java/nutsandbolts/opsummary.html and wonder about increment/decrement/shifts etc.... :-) Also noting that Integer.rotateLeft() and friends exist, so the shifts might well fit there. Stephen On 5 December 2012 22:53, Brian Goetz wrote: > Here, we're adding things that could be converted to SAMs, and logicalNot > could be converted to a UnaryOperator, so, there's a case :) > > > On 12/5/2012 5:26 PM, Stephen Colebourne wrote: >> >> On 5 December 2012 21:27, Akhil Arora wrote: >>> >>> Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/ >>> >>> - delegate to Math.min/max for int/long/float/double >>> - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor >> >> >> Is there a case for logicalNot() ? >> >> Stephen >> > From c.mallwitz at gmail.com Wed Dec 5 15:39:34 2012 From: c.mallwitz at gmail.com (Christian Mallwitz) Date: Wed, 5 Dec 2012 23:39:34 +0000 Subject: StreamOpFlag.* and OutOfMemoryError when going parall In-Reply-To: <50BF9C6D.9000008@univ-mlv.fr> References: <50BF93A7.8000400@oracle.com> <50BF9C6D.9000008@univ-mlv.fr> Message-ID: I was experimenting with a few lambda examples and tried to generate the first 1000 prime numbers by - create an iterator to generating an infinite amount numbers - filter prime numbers - limit the filtered number to 1000 The serial version is working as expected keeping one CPU core busy. My hope was that the parallel version would do the prime number testing bit on all cores and then stop when it has collected 1000 prime numbers (and stop pulling further numbers from the iterator to test them for primality) As Brian pointed out, because the limit() isn't fully lazy, this results in an OutOfMemoryError because actually calculating _all_ prime numbers this way and _then_ limit the result set isn't really an option. Now I wonder whether I could build a better limit() version myself... Christian On Wed, Dec 5, 2012 at 7:11 PM, Remi Forax wrote: > On 12/05/2012 07:54 PM, Christian Mallwitz wrote: >> Very well :-) >> >> Leaving the parallel aspect aside, If I just wanted to find the first >> n prime numbers based on a possibly infinity stream of numbers (I >> don't want to use a Collection with a known size), is there another >> 'officially' approved way to covert an Iterator to a Stream (instead >> of using Streams.stream())? > > I understand what you want to do but I don't understand how you want the > code to work in parallel. > >> >> Regarding a fully lazy, parallel limit() and its future: does 'future' >> mean pre- or post-JDK8? >> >> Cheers! >> Christian > > regards, > R?mi > > From joe.darcy at oracle.com Wed Dec 5 15:44:53 2012 From: joe.darcy at oracle.com (Joseph Darcy) Date: Wed, 05 Dec 2012 15:44:53 -0800 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50BFBC49.9020200@oracle.com> References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com> <50BFBC49.9020200@oracle.com> Message-ID: <50BFDC75.6000306@oracle.com> Akhil, In javadoc like this 298 * as {@code BinaryOperator<Boolean>}. you don't have to use "<" and the like inside {@code}; please change to 298 * as {@code BinaryOperator}. As a general comment, if the operations for primitive type Foo are put into java.lang.Foo, then the type of the operation needs to be explicitly represented in the expression calling the method (unless static imports are used, etc.). Therefore, I suggest putting these sort of static methods all into one class to allow overloading to do its thing (java.lang.Operators?). Also, for methods like sum, I think it is worth considering returning a larger type than the operands to avoid problems from integer or floating-point overflow. For example, sum on byte and short would return int, sun on int would return long, etc. As an aside, to get a numerically robust result, the summation logic over a set of doubles needs to be more than just a set of raw double additions, but that can be tackled later. Cheers, -Joe On 12/5/2012 1:27 PM, Akhil Arora wrote: > Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/ > > - delegate to Math.min/max for int/long/float/double > - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor > - removed Character variants of min/max/sum > > On 12/02/2012 05:50 PM, David Holmes wrote: >> Hi Akhil, >> >> Is it really necessary/desirable to flag all of these as " Suitable for >> conversion as a method reference to functional interfaces such as ..." ? > Not necessary, but it does provide a hint as to their intended use to a > casual browser of these docs. > >> This style: >> >> + * @param a a boolean argument. >> + * @param b another boolean argument. >> >> is at odds with the style used elsewhere for new Functional APIs, and >> with the style of other methods in these classes. Can we just use "first >> operand" and "second operand" for all of these? > It is consistent with Math.min/max, which use the a/b style. Since these > methods are not in one of the functional package, is'nt it better to > stick to the local style? > >> Character.sum does not make sense to me. Who adds together characters? >> I'm not even sure min and max are worth supporting for Character. > Good point - removed these methods for Character. > >> I disagree with other suggestions to use the Math functions for >> float/double. I think all these methods should use the underlying >> primitive operator regardless of type. > Are you disagreeing only for float/double or for int/long also? Can you > provide more information as to why you disagree? > > Thanks > >> Thanks, >> David >> ----- >> >> On 1/12/2012 4:44 AM, Akhil Arora wrote: >>> Hi >>> >>> Requesting review for some basic functionality related to lambdas - >>> >>> Add min, max, sum methods to the primitive wrapper classes - Byte, >>> Short, Integer, Long, Float, Double and Character so as to be able to >>> use them as reducers in lambda expressions. Add and, or, xor methods to >>> Boolean. >>> >>> http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201 >>> >>> Thanks > From mike.duigou at oracle.com Wed Dec 5 16:20:29 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 06 Dec 2012 00:20:29 +0000 Subject: hg: lambda/lambda/jdk: add primitives specializations for Predicate Message-ID: <20121206002045.BB34347EE0@hg.openjdk.java.net> Changeset: 904f03a1373b Author: mduigou Date: 2012-12-05 16:20 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/904f03a1373b add primitives specializations for Predicate + src/share/classes/java/util/function/DoublePredicate.java + src/share/classes/java/util/function/IntPredicate.java + src/share/classes/java/util/function/LongPredicate.java From mike.duigou at oracle.com Wed Dec 5 18:06:56 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 06 Dec 2012 02:06:56 +0000 Subject: hg: lambda/lambda/jdk: 8001647: In-place methods on Collection/List and tests Message-ID: <20121206020707.B5C8247EE6@hg.openjdk.java.net> Changeset: c2804bf96f5f Author: akhil Date: 2012-12-05 18:06 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c2804bf96f5f 8001647: In-place methods on Collection/List and tests ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java - test-ng/tests/org/openjdk/tests/java/util/CollectionTest.java - test-ng/tests/org/openjdk/tests/java/util/IterableTest.java - test-ng/tests/org/openjdk/tests/java/util/ListTest.java + test/java/util/CollectionExtensionMethods/CollectionExtensionMethodsTest.java + test/java/util/CollectionExtensionMethods/ListExtensionMethodsTest.java + test/java/util/CollectionExtensionMethods/testlibrary/CollectionAsserts.java + test/java/util/CollectionExtensionMethods/testlibrary/CollectionSupplier.java From brian.goetz at oracle.com Wed Dec 5 19:23:55 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 05 Dec 2012 22:23:55 -0500 Subject: StreamOpFlag.* and OutOfMemoryError when going parall In-Reply-To: References: <50BF93A7.8000400@oracle.com> <50BF9C6D.9000008@univ-mlv.fr> Message-ID: <50C00FCB.5060907@oracle.com> > As Brian pointed out, because the limit() isn't fully lazy, this > results in an OutOfMemoryError because actually calculating _all_ > prime numbers this way and _then_ limit the result set isn't really an > option. Now I wonder whether I could build a better limit() version > myself... No, that's not exactly right. The decomposition is left-spine (so it should compute the leftmost ones earlier) and it cancels once its found enough. But it may well compute more than 1000. It sounds like something else is wrong. It shouldn't OOME on such a small problem. From david.holmes at oracle.com Wed Dec 5 22:06:45 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Dec 2012 16:06:45 +1000 Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> Message-ID: <50C035F5.4050007@oracle.com> On 6/12/2012 4:20 AM, Mike Duigou wrote: > I have updated webrev again to fix some reported javadoc technical issues and added null handling specification to the {Int|Double|Long}Supplier. > > http://cr.openjdk.java.net/~mduigou/8004015/2/webrev/ > http://cr.openjdk.java.net/~mduigou/8004015/2/specdiff/java/util/function/package-summary.html > > I believe that this iteration is complete (or very nearly so). Sorry to be a pain but this: left - the left operand, must be non-null doesn't tell you what happens if it is null. Is it not better to simply have: @param left the left operand @param right the right operand @throws NullPointerException if either left or right are null ? David ----- > Mike > > On Dec 4 2012, at 21:47 , Mike Duigou wrote: > >> Hello all; >> >> I have updated the proposed patch. The changes primarily add class and method documentation regarding handling of null for the primitive specializations. >> >> http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/ >> http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html >> >> I've also reformatted the source for the default methods. >> >> Mike >> >> >> On Nov 26 2012, at 18:12 , Mike Duigou wrote: >> >>> Hello all; >>> >>> In the original patch which added the basic lambda functional interfaces, CR#8001634 [1], none of the interfaces extended other interfaces. The reason was primarily that the javac compiler did not, at the time that 8001634 was proposed, support extension methods. The compiler now supports adding of method defaults so this patch improves the functional interfaces by filing in the inheritance hierarchy. >>> >>> Adding the parent interfaces and default methods allows each functional interface to be used in more places. It is especially important for the functional interfaces which support primitive types, IntSupplier, IntFunction, IntUnaryOperator, IntBinaryOperator, etc. We expect that eventually standard implementations of these interfaces will be provided for functions like max, min, sum, etc. By extending the reference oriented functional interfaces such as Function, the primitive implementations can be used with the boxed primitive types along with the primitive types for which they are defined. >>> >>> The patch to add parent interfaces and default methods can be found here: >>> >>> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ >>> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html >>> >>> Mike >>> >>> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697 >> > > From henry.jen at oracle.com Wed Dec 5 22:57:23 2012 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 05 Dec 2012 22:57:23 -0800 Subject: Request for Review: CR#8001667, second attempt Message-ID: <50C041D3.9060703@oracle.com> Hi, This update reflect changes based on feedbacks for last version, the changes are - rename reverse() to reverseOrder() - rename Comparator.compose to Comparator.thenComparing - add 4 Comparator.thenComparing methods take [Int|Long|Double]Function to enable fluent syntax like this example, people.sort(Comparators.comparing(People::getFirstName).thenComparing(People.getLastName)) vs previously, people.sort(Comparators.comparing(Person::getName)) Comparator byLastFirst = Comparators.comparing(Person::getLastName) .compose(Comparators.comparing(Person::getFirstName)) Please review and comment on the webrev[1] and specdiff[2]. [1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.1/webrev [2] http://cr.openjdk.java.net/~henryjen/ccc/8001667.1/specdiff/overview-summary.html Cheers, Henry From paul.sandoz at oracle.com Thu Dec 6 00:59:27 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 06 Dec 2012 08:59:27 +0000 Subject: hg: lambda/lambda/jdk: - SliceOp unified for reference and int stream. Message-ID: <20121206085949.8EBF447EFB@hg.openjdk.java.net> Changeset: 3ba3ec7b861a Author: psandoz Date: 2012-12-06 09:58 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3ba3ec7b861a - SliceOp unified for reference and int stream. - StreamShape exposes a NodeFactory for various Node creation functionality ! src/share/classes/java/util/stream/AbstractPipeline.java + src/share/classes/java/util/stream/NodeFactory.java ! src/share/classes/java/util/stream/PipelineHelper.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/StreamShape.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/op/IntermediateOp.java ! src/share/classes/java/util/stream/op/SliceOp.java - src/share/classes/java/util/stream/primitive/IntLimitOp.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntStream.java ! src/share/classes/java/util/stream/primitive/IntToIntegerOp.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SliceOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntSliceOpTest.java From paul.sandoz at oracle.com Thu Dec 6 01:24:45 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 06 Dec 2012 09:24:45 +0000 Subject: hg: lambda/lambda/jdk: - use j.u.functions.IntPredicate Message-ID: <20121206092456.F101147F01@hg.openjdk.java.net> Changeset: 63d2b3e94105 Author: psandoz Date: 2012-12-06 10:24 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/63d2b3e94105 - use j.u.functions.IntPredicate - move auxillary class AbstractShortCircuitTask to top-level class + src/share/classes/java/util/stream/op/AbstractShortCircuitTask.java ! src/share/classes/java/util/stream/op/AbstractTask.java ! src/share/classes/java/util/stream/op/MatchOp.java ! src/share/classes/java/util/stream/primitive/IntFilterOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java - src/share/classes/java/util/stream/primitive/IntPredicate.java ! src/share/classes/java/util/stream/primitive/IntStream.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MatchOpTest.java From scolebourne at joda.org Thu Dec 6 02:23:26 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 6 Dec 2012 10:23:26 +0000 Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: <50C035F5.4050007@oracle.com> References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> <50C035F5.4050007@oracle.com> Message-ID: On 6 December 2012 06:06, David Holmes wrote: > On 6/12/2012 4:20 AM, Mike Duigou wrote: >> >> I have updated webrev again to fix some reported javadoc technical issues >> and added null handling specification to the {Int|Double|Long}Supplier. >> >> http://cr.openjdk.java.net/~mduigou/8004015/2/webrev/ >> >> http://cr.openjdk.java.net/~mduigou/8004015/2/specdiff/java/util/function/package-summary.html >> >> I believe that this iteration is complete (or very nearly so). > > Sorry to be a pain but this: > > left - the left operand, must be non-null > > doesn't tell you what happens if it is null. Is it not better to simply > have: > > @param left the left operand > @param right the right operand > @throws NullPointerException if either left or right are null Whereas I use: @param left the left operand, not null @param right the right operand, not null There is an element of taste here. As I wrote up http://blog.joda.org/2012/11/javadoc-coding-standards.html Javadoc is read as source code as often as it is read as HTML. Thus, not overly cluttering is important. IMO, the @throws NPE is implied by the assertion of "not null" or "must be non-null". More importantly, the use of @param scales better. For example, there is often a case where null is treated as a default or special value. The Javadoc would then look something like @param left the left operand, null treated as zero @param right the right operand, null treated as zero This kind of information belongs with the @param, and for consistency it is much better to also have the "not null" aspect on the @param as well. (Everything together is easier for developers to parse) In summary, while I prefer my "not null" to Mike's "must be non-null", what is proposed is fine, and better than your (David's) proposal. Stephen From scolebourne at joda.org Thu Dec 6 02:29:00 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 6 Dec 2012 10:29:00 +0000 Subject: Request for Review: CR#8001667, second attempt In-Reply-To: <50C041D3.9060703@oracle.com> References: <50C041D3.9060703@oracle.com> Message-ID: On 6 December 2012 06:57, Henry Jen wrote: > Please review and comment on the webrev[1] and specdiff[2]. > > [1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.1/webrev > [2] > http://cr.openjdk.java.net/~henryjen/ccc/8001667.1/specdiff/overview-summary.html Are you allowed to change the copyright date? I also note that the generic catch-all null statement at the class level is less usable than a "not null" or "must be non-null" on each @param. Stephen From paul.sandoz at oracle.com Thu Dec 6 03:24:50 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 6 Dec 2012 12:24:50 +0100 Subject: StreamOpFlag.* and OutOfMemoryError when going parall In-Reply-To: <50C00FCB.5060907@oracle.com> References: <50BF93A7.8000400@oracle.com> <50BF9C6D.9000008@univ-mlv.fr> <50C00FCB.5060907@oracle.com> Message-ID: On Dec 6, 2012, at 4:23 AM, Brian Goetz wrote: >> As Brian pointed out, because the limit() isn't fully lazy, this >> results in an OutOfMemoryError because actually calculating _all_ >> prime numbers this way and _then_ limit the result set isn't really an >> option. Now I wonder whether I could build a better limit() version >> myself... > > No, that's not exactly right. The decomposition is left-spine (so it > should compute the leftmost ones earlier) and it cancels once its found > enough. But it may well compute more than 1000. > > It sounds like something else is wrong. It shouldn't OOME on such a > small problem. > It can just be limit(1) and it will still fail with an OOME. The problem is the isLeftSpine() will always fail for the shape of tree generated by Iterators.spliterator() since nodes in the right spine will never complete. I think we will need to put some logic into the leaf nodes such that on completion of a leaf it looks at all the siblings to the left of itself and short-cicuits and forces completion of the parent if a match of the slice/offset is found. Also even though we don't know the complete size we may know sizes at certain depths, which could be leveraged to enable better slice calculations and avoid buffering on skipping. Paul. From chris.hegarty at oracle.com Thu Dec 6 03:59:58 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 06 Dec 2012 11:59:58 +0000 Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: <50C035F5.4050007@oracle.com> References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> <50C035F5.4050007@oracle.com> Message-ID: <50C088BE.1040403@oracle.com> Mike, Some small comments. 1) IntUnaryOperator.java Typo in: + 30 *

This is the primitive type specialization of {@link IntUnaryOperator} for + 31 * {@code int} and also may be used as a {@code IntUnaryOperator}. When + 32 * used as a {@code IntUnaryOperator} the default {@code operate} implementation + 33 * provided by this interface neither accepts null parameters nor does it return + 34 * null results. IntUnaryOperator -> UnaryOperator 2) Double/Int/Long Function "When used as a Function the default apply implementation provided by this interface neither accepts null parameters nor does it return null results." "When used as a Function", is this really necessary, or should the behavior of the default apply method just be described? Why the restriction on null parameters, it seems overly restrictive since applyAsXXXX accepts nulls, right? 3) package description "null values are accepted and returned by these functional interfaces according to the constraints of the specification in which the functional interfaces are used. The functional interfaces themselves do not constrain or mandate use of null values. Most usages of the functional interfaces will define the role, if any, of null for that context." Given these changes, doesn't this need to be reworked ( to indicate that some methods specify null value behavior)? 4) Trivially, IntSupplier is missing a '

', before "This is the primitive type..." 5) I agree with David, NPE should be defined where applicable. -Chris. On 12/06/2012 06:06 AM, David Holmes wrote: > On 6/12/2012 4:20 AM, Mike Duigou wrote: >> I have updated webrev again to fix some reported javadoc technical >> issues and added null handling specification to the >> {Int|Double|Long}Supplier. >> >> http://cr.openjdk.java.net/~mduigou/8004015/2/webrev/ >> http://cr.openjdk.java.net/~mduigou/8004015/2/specdiff/java/util/function/package-summary.html >> >> >> I believe that this iteration is complete (or very nearly so). > > Sorry to be a pain but this: > > left - the left operand, must be non-null > > doesn't tell you what happens if it is null. Is it not better to simply > have: > > @param left the left operand > @param right the right operand > @throws NullPointerException if either left or right are null > > ? > > David > ----- > > >> Mike >> >> On Dec 4 2012, at 21:47 , Mike Duigou wrote: >> >>> Hello all; >>> >>> I have updated the proposed patch. The changes primarily add class >>> and method documentation regarding handling of null for the primitive >>> specializations. >>> >>> http://cr.openjdk.java.net/~mduigou/8004015/1/webrev/ >>> http://cr.openjdk.java.net/~mduigou/8004015/1/specdiff/java/util/function/package-summary.html >>> >>> >>> I've also reformatted the source for the default methods. >>> >>> Mike >>> >>> >>> On Nov 26 2012, at 18:12 , Mike Duigou wrote: >>> >>>> Hello all; >>>> >>>> In the original patch which added the basic lambda functional >>>> interfaces, CR#8001634 [1], none of the interfaces extended other >>>> interfaces. The reason was primarily that the javac compiler did >>>> not, at the time that 8001634 was proposed, support extension >>>> methods. The compiler now supports adding of method defaults so this >>>> patch improves the functional interfaces by filing in the >>>> inheritance hierarchy. >>>> >>>> Adding the parent interfaces and default methods allows each >>>> functional interface to be used in more places. It is especially >>>> important for the functional interfaces which support primitive >>>> types, IntSupplier, IntFunction, IntUnaryOperator, >>>> IntBinaryOperator, etc. We expect that eventually standard >>>> implementations of these interfaces will be provided for functions >>>> like max, min, sum, etc. By extending the reference oriented >>>> functional interfaces such as Function, the primitive >>>> implementations can be used with the boxed primitive types along >>>> with the primitive types for which they are defined. >>>> >>>> The patch to add parent interfaces and default methods can be found >>>> here: >>>> >>>> http://cr.openjdk.java.net/~mduigou/8004015/0/webrev/ >>>> http://cr.openjdk.java.net/~mduigou/8004015/0/specdiff/java/util/function/package-summary.html >>>> >>>> >>>> Mike >>>> >>>> [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e80176a697 >>> >> >> From david.holmes at oracle.com Thu Dec 6 04:42:59 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Dec 2012 22:42:59 +1000 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50BFBC49.9020200@oracle.com> References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com> <50BFBC49.9020200@oracle.com> Message-ID: <50C092D3.4020201@oracle.com> On 6/12/2012 7:27 AM, Akhil Arora wrote: > Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/ > > - delegate to Math.min/max for int/long/float/double > - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor > - removed Character variants of min/max/sum > > On 12/02/2012 05:50 PM, David Holmes wrote: >> Is it really necessary/desirable to flag all of these as " Suitable for >> conversion as a method reference to functional interfaces such as ..." ? > > Not necessary, but it does provide a hint as to their intended use to a > casual browser of these docs. I don't find it desirable either. >> This style: >> >> + * @param a a boolean argument. >> + * @param b another boolean argument. >> >> is at odds with the style used elsewhere for new Functional APIs, and >> with the style of other methods in these classes. Can we just use "first >> operand" and "second operand" for all of these? > > It is consistent with Math.min/max, which use the a/b style. Since these > methods are not in one of the functional package, is'nt it better to > stick to the local style? Why do you consider Math to be representative of "local style"? Math isn't even internally consistent with its style - see Math.max versus Math.addExact etc. And Math doesn't include the arguments type in its description. (Consistency is not a strong point in the Java APIs :( ) Given these are being added to support the new functional type I suggest using the same style as for the functional types. >> Character.sum does not make sense to me. Who adds together characters? >> I'm not even sure min and max are worth supporting for Character. > > Good point - removed these methods for Character. > >> I disagree with other suggestions to use the Math functions for >> float/double. I think all these methods should use the underlying >> primitive operator regardless of type. > > Are you disagreeing only for float/double or for int/long also? Can you > provide more information as to why you disagree? I withdraw my objection. David ----- > Thanks > >> Thanks, >> David >> ----- >> >> On 1/12/2012 4:44 AM, Akhil Arora wrote: >>> Hi >>> >>> Requesting review for some basic functionality related to lambdas - >>> >>> Add min, max, sum methods to the primitive wrapper classes - Byte, >>> Short, Integer, Long, Float, Double and Character so as to be able to >>> use them as reducers in lambda expressions. Add and, or, xor methods to >>> Boolean. >>> >>> http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ >>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201 >>> >>> Thanks > From david.holmes at oracle.com Thu Dec 6 04:47:14 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 06 Dec 2012 22:47:14 +1000 Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> <50C035F5.4050007@oracle.com> Message-ID: <50C093D2.3090909@oracle.com> Stephen, I believe that exceptions thrown should be identified using @throws - not implied. I think @param is for giving the basic description of a parameter not for explaining the semantics, or what different values of the parameter mean. YMMV David On 6/12/2012 8:23 PM, Stephen Colebourne wrote: > On 6 December 2012 06:06, David Holmes wrote: >> On 6/12/2012 4:20 AM, Mike Duigou wrote: >>> >>> I have updated webrev again to fix some reported javadoc technical issues >>> and added null handling specification to the {Int|Double|Long}Supplier. >>> >>> http://cr.openjdk.java.net/~mduigou/8004015/2/webrev/ >>> >>> http://cr.openjdk.java.net/~mduigou/8004015/2/specdiff/java/util/function/package-summary.html >>> >>> I believe that this iteration is complete (or very nearly so). >> >> Sorry to be a pain but this: >> >> left - the left operand, must be non-null >> >> doesn't tell you what happens if it is null. Is it not better to simply >> have: >> >> @param left the left operand >> @param right the right operand >> @throws NullPointerException if either left or right are null > > Whereas I use: > @param left the left operand, not null > @param right the right operand, not null > > There is an element of taste here. As I wrote up > http://blog.joda.org/2012/11/javadoc-coding-standards.html > Javadoc is read as source code as often as it is read as HTML. Thus, > not overly cluttering is important. > IMO, the @throws NPE is implied by the assertion of "not null" or > "must be non-null". > > More importantly, the use of @param scales better. For example, there > is often a case where null is treated as a default or special value. > The Javadoc would then look something like > > @param left the left operand, null treated as zero > @param right the right operand, null treated as zero > > This kind of information belongs with the @param, and for consistency > it is much better to also have the "not null" aspect on the @param as > well. (Everything together is easier for developers to parse) > > In summary, while I prefer my "not null" to Mike's "must be non-null", > what is proposed is fine, and better than your (David's) proposal. > > Stephen > From paul.sandoz at oracle.com Thu Dec 6 07:54:12 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 06 Dec 2012 15:54:12 +0000 Subject: hg: lambda/lambda/jdk: - A functional but terribly inefficient implementation of IntStream.uniqueElements. Message-ID: <20121206155506.2433B47F29@hg.openjdk.java.net> Changeset: 6c267e5fdf36 Author: psandoz Date: 2012-12-06 16:53 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6c267e5fdf36 - A functional but terribly inefficient implementation of IntStream.uniqueElements. ! src/share/classes/java/util/stream/primitive/IntPipeline.java + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntUniqOpTest.java From mike.duigou at oracle.com Thu Dec 6 07:56:09 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 6 Dec 2012 07:56:09 -0800 Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: <50C093D2.3090909@oracle.com> References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> <50C035F5.4050007@oracle.com> <50C093D2.3090909@oracle.com> Message-ID: <7DC6E3DE-9C1A-4DC6-8B26-E385C7882F44@oracle.com> Something seems entirely out of balance regarding handling of null. If a methods says that it takes a reference type then why ever might it be assumed that null is permitted? It feels more than a bit like we are adding "no naked people" stickers to every building entrance and "do not insert fingers" to every electrical outlet. The "@throws NPE" are yet another layer of "Violators will be arrested" or "You will be electrocuted" stickers. It seems entirely wrongheaded to assume that null could be passed in place of a valid reference unless explicitly and categorically forbidden. Accepting null should be considered extraordinary and worthy of mention only when it occurs. Being rare it would also be a lot easier to document. So really, why mention null at all? Mike On Dec 6 2012, at 04:47 , David Holmes wrote: > Stephen, > > I believe that exceptions thrown should be identified using @throws - not implied. > > I think @param is for giving the basic description of a parameter not for explaining the semantics, or what different values of the parameter mean. > > YMMV > > David > > On 6/12/2012 8:23 PM, Stephen Colebourne wrote: >> On 6 December 2012 06:06, David Holmes wrote: >>> On 6/12/2012 4:20 AM, Mike Duigou wrote: >>>> >>>> I have updated webrev again to fix some reported javadoc technical issues >>>> and added null handling specification to the {Int|Double|Long}Supplier. >>>> >>>> http://cr.openjdk.java.net/~mduigou/8004015/2/webrev/ >>>> >>>> http://cr.openjdk.java.net/~mduigou/8004015/2/specdiff/java/util/function/package-summary.html >>>> >>>> I believe that this iteration is complete (or very nearly so). >>> >>> Sorry to be a pain but this: >>> >>> left - the left operand, must be non-null >>> >>> doesn't tell you what happens if it is null. Is it not better to simply >>> have: >>> >>> @param left the left operand >>> @param right the right operand >>> @throws NullPointerException if either left or right are null >> >> Whereas I use: >> @param left the left operand, not null >> @param right the right operand, not null >> >> There is an element of taste here. As I wrote up >> http://blog.joda.org/2012/11/javadoc-coding-standards.html >> Javadoc is read as source code as often as it is read as HTML. Thus, >> not overly cluttering is important. >> IMO, the @throws NPE is implied by the assertion of "not null" or >> "must be non-null". >> >> More importantly, the use of @param scales better. For example, there >> is often a case where null is treated as a default or special value. >> The Javadoc would then look something like >> >> @param left the left operand, null treated as zero >> @param right the right operand, null treated as zero >> >> This kind of information belongs with the @param, and for consistency >> it is much better to also have the "not null" aspect on the @param as >> well. (Everything together is easier for developers to parse) >> >> In summary, while I prefer my "not null" to Mike's "must be non-null", >> what is proposed is fine, and better than your (David's) proposal. >> >> Stephen >> From maurizio.cimadamore at oracle.com Thu Dec 6 08:18:39 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 06 Dec 2012 16:18:39 +0000 Subject: hg: lambda/lambda/langtools: Fix: static interface methods cannot be called due to hiding bug Message-ID: <20121206161847.4A47A47F2C@hg.openjdk.java.net> Changeset: 226061853b60 Author: mcimadamore Date: 2012-12-06 16:18 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/226061853b60 Fix: static interface methods cannot be called due to hiding bug ! src/share/classes/com/sun/tools/javac/code/Symbol.java - test/tools/javac/defaultMethods/hiding/InterfaceMethodHidingTest.java + test/tools/javac/defaultMethods/static/Static01.java + test/tools/javac/defaultMethods/static/hiding/InterfaceMethodHidingTest.java From joe.bowbeer at gmail.com Thu Dec 6 08:18:16 2012 From: joe.bowbeer at gmail.com (Joe Bowbeer) Date: Thu, 6 Dec 2012 08:18:16 -0800 Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: <7DC6E3DE-9C1A-4DC6-8B26-E385C7882F44@oracle.com> References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> <50C035F5.4050007@oracle.com> <50C093D2.3090909@oracle.com> <7DC6E3DE-9C1A-4DC6-8B26-E385C7882F44@oracle.com> Message-ID: The documentation for Collection.add is not a reasonable model to emulate? http://docs.oracle.com/javase/6/docs/api/java/util/Collection.html#add(E) It is written from the standpoint that nulls are OK, but notes that some implementations might barf, and lists NPE among the possible exceptions. I think that's the right approach for streams as well. In a wide range of popular APIs, there are lots of methods that return null, and it is these nulls that are the most likely to show up in functionally-constructed streams. Java programmers do have the notion that nulls might not be allowed everywhere, and will look to the javadoc for clarification. On Thu, Dec 6, 2012 at 7:56 AM, Mike Duigou wrote: > Something seems entirely out of balance regarding handling of null. If a > methods says that it takes a reference type then why ever might it be > assumed that null is permitted? > > It feels more than a bit like we are adding "no naked people" stickers to > every building entrance and "do not insert fingers" to every electrical > outlet. The "@throws NPE" are yet another layer of "Violators will be > arrested" or "You will be electrocuted" stickers. > > It seems entirely wrongheaded to assume that null could be passed in place > of a valid reference unless explicitly and categorically forbidden. > Accepting null should be considered extraordinary and worthy of mention > only when it occurs. Being rare it would also be a lot easier to document. > > So really, why mention null at all? > > Mike > > On Dec 6 2012, at 04:47 , David Holmes wrote: > > > Stephen, > > > > I believe that exceptions thrown should be identified using @throws - > not implied. > > > > I think @param is for giving the basic description of a parameter not > for explaining the semantics, or what different values of the parameter > mean. > > > > YMMV > > > > David > > > > On 6/12/2012 8:23 PM, Stephen Colebourne wrote: > >> On 6 December 2012 06:06, David Holmes wrote: > >>> On 6/12/2012 4:20 AM, Mike Duigou wrote: > >>>> > >>>> I have updated webrev again to fix some reported javadoc technical > issues > >>>> and added null handling specification to the > {Int|Double|Long}Supplier. > >>>> > >>>> http://cr.openjdk.java.net/~mduigou/8004015/2/webrev/ > >>>> > >>>> > http://cr.openjdk.java.net/~mduigou/8004015/2/specdiff/java/util/function/package-summary.html > >>>> > >>>> I believe that this iteration is complete (or very nearly so). > >>> > >>> Sorry to be a pain but this: > >>> > >>> left - the left operand, must be non-null > >>> > >>> doesn't tell you what happens if it is null. Is it not better to simply > >>> have: > >>> > >>> @param left the left operand > >>> @param right the right operand > >>> @throws NullPointerException if either left or right are null > >> > >> Whereas I use: > >> @param left the left operand, not null > >> @param right the right operand, not null > >> > >> There is an element of taste here. As I wrote up > >> http://blog.joda.org/2012/11/javadoc-coding-standards.html > >> Javadoc is read as source code as often as it is read as HTML. Thus, > >> not overly cluttering is important. > >> IMO, the @throws NPE is implied by the assertion of "not null" or > >> "must be non-null". > >> > >> More importantly, the use of @param scales better. For example, there > >> is often a case where null is treated as a default or special value. > >> The Javadoc would then look something like > >> > >> @param left the left operand, null treated as zero > >> @param right the right operand, null treated as zero > >> > >> This kind of information belongs with the @param, and for consistency > >> it is much better to also have the "not null" aspect on the @param as > >> well. (Everything together is easier for developers to parse) > >> > >> In summary, while I prefer my "not null" to Mike's "must be non-null", > >> what is proposed is fine, and better than your (David's) proposal. > >> > >> Stephen > >> > > From scolebourne at joda.org Thu Dec 6 08:23:55 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 6 Dec 2012 16:23:55 +0000 Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: <7DC6E3DE-9C1A-4DC6-8B26-E385C7882F44@oracle.com> References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> <50C035F5.4050007@oracle.com> <50C093D2.3090909@oracle.com> <7DC6E3DE-9C1A-4DC6-8B26-E385C7882F44@oracle.com> Message-ID: On 6 December 2012 15:56, Mike Duigou wrote: > Something seems entirely out of balance regarding handling of null. If a methods says that it takes a reference type then why ever might it be assumed that null is permitted? > > It feels more than a bit like we are adding "no naked people" stickers to every building entrance and "do not insert fingers" to every electrical outlet. The "@throws NPE" are yet another layer of "Violators will be arrested" or "You will be electrocuted" stickers. > > It seems entirely wrongheaded to assume that null could be passed in place of a valid reference unless explicitly and categorically forbidden. Accepting null should be considered extraordinary and worthy of mention only when it occurs. Being rare it would also be a lot easier to document. > > So really, why mention null at all? Null pointer exceptions are extremely common and costly. Sadly despite asking, there seems to be no movement to handle the issue at what I consider to be the root cause, lack of type-system support to distinguish nullable from non-null references (annotations are not the solution here). So, all we have is Javadoc. If I had enough time, I would hassle every webrev until they documented nulls properly. Absence of information at the method level effectively tells me nothing. The balance you seek is IMO what I do - two words on the end of the @param. Mine is deliberately short and without @throws to avoid the clutter you rightly sense could happen. Stephen From brian.goetz at oracle.com Thu Dec 6 08:28:22 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 06 Dec 2012 16:28:22 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121206162844.F282E47F2F@hg.openjdk.java.net> Changeset: 0d5073cdc9d6 Author: briangoetz Date: 2012-12-06 11:27 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0d5073cdc9d6 Rationalize functional forms of reduce/fold; rename all to reduce; first cut at mutable forms ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/op/FoldOp.java ! src/share/classes/java/util/stream/op/OpUtils.java - src/share/classes/java/util/stream/op/SeedlessFoldOp.java ! src/share/classes/java/util/stream/op/SliceOp.java ! src/share/classes/java/util/stream/op/TreeUtils.java ! src/share/classes/java/util/stream/primitive/IntTreeUtils.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ReduceTest.java Changeset: cf8b861b44ff Author: briangoetz Date: 2012-12-06 11:28 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cf8b861b44ff Merge ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/op/SliceOp.java - src/share/classes/java/util/stream/primitive/IntLimitOp.java - src/share/classes/java/util/stream/primitive/IntPredicate.java - test-ng/tests/org/openjdk/tests/java/util/CollectionTest.java - test-ng/tests/org/openjdk/tests/java/util/IterableTest.java - test-ng/tests/org/openjdk/tests/java/util/ListTest.java From Lance.Andersen at oracle.com Thu Dec 6 09:01:09 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 6 Dec 2012 12:01:09 -0500 Subject: signatures that are recorded for default methods Message-ID: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> Folks, Will the signatures for interfaces that are recorded by the TCKs for interfaces record the fact that a method includes a default method? or will it just record the method definition? I am assuming it will, but I know there has been discussion that a implementor could choose a different default implementation on one of the recent threads that was up for review. I am still trying to understand what our guidelines are, if any for documenting the behavior of the supplied default methods given the javadocs are part of the specification for many APIs (and in some case the only spec). Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From brian.goetz at oracle.com Thu Dec 6 09:35:27 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 06 Dec 2012 12:35:27 -0500 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50BFDC75.6000306@oracle.com> References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com> <50BFBC49.9020200@oracle.com> <50BFDC75.6000306@oracle.com> Message-ID: <50C0D75F.3030705@oracle.com> This suggestion makes me nervous, because we're already asking a great deal of type inference. If you say reduce(Operators::plus) and there are eight versions of Operators to choose from (and add boxing into the mix), I think we'll see a lot more inference errors. If the user says Integer::plus, the user has already told us what we want, and we're done. On 12/5/2012 6:44 PM, Joseph Darcy wrote: > Akhil, > > In javadoc like this > > 298 * as {@code BinaryOperator<Boolean>}. > > you don't have to use "<" and the like inside {@code}; please change to > > 298 * as {@code BinaryOperator}. > > As a general comment, if the operations for primitive type Foo are put > into java.lang.Foo, then the type of the operation needs to be > explicitly represented in the expression calling the method (unless > static imports are used, etc.). Therefore, I suggest putting these sort > of static methods all into one class to allow overloading to do its > thing (java.lang.Operators?). Also, for methods like sum, I think it is > worth considering returning a larger type than the operands to avoid > problems from integer or floating-point overflow. For example, sum on > byte and short would return int, sun on int would return long, etc. > > As an aside, to get a numerically robust result, the summation logic > over a set of doubles needs to be more than just a set of raw double > additions, but that can be tackled later. > > Cheers, > > -Joe > > > On 12/5/2012 1:27 PM, Akhil Arora wrote: >> Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/ >> >> - delegate to Math.min/max for int/long/float/double >> - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor >> - removed Character variants of min/max/sum >> >> On 12/02/2012 05:50 PM, David Holmes wrote: >>> Hi Akhil, >>> >>> Is it really necessary/desirable to flag all of these as " Suitable for >>> conversion as a method reference to functional interfaces such as ..." ? >> Not necessary, but it does provide a hint as to their intended use to a >> casual browser of these docs. >> >>> This style: >>> >>> + * @param a a boolean argument. >>> + * @param b another boolean argument. >>> >>> is at odds with the style used elsewhere for new Functional APIs, and >>> with the style of other methods in these classes. Can we just use "first >>> operand" and "second operand" for all of these? >> It is consistent with Math.min/max, which use the a/b style. Since these >> methods are not in one of the functional package, is'nt it better to >> stick to the local style? >> >>> Character.sum does not make sense to me. Who adds together characters? >>> I'm not even sure min and max are worth supporting for Character. >> Good point - removed these methods for Character. >> >>> I disagree with other suggestions to use the Math functions for >>> float/double. I think all these methods should use the underlying >>> primitive operator regardless of type. >> Are you disagreeing only for float/double or for int/long also? Can you >> provide more information as to why you disagree? >> >> Thanks >> >>> Thanks, >>> David >>> ----- >>> >>> On 1/12/2012 4:44 AM, Akhil Arora wrote: >>>> Hi >>>> >>>> Requesting review for some basic functionality related to lambdas - >>>> >>>> Add min, max, sum methods to the primitive wrapper classes - Byte, >>>> Short, Integer, Long, Float, Double and Character so as to be able to >>>> use them as reducers in lambda expressions. Add and, or, xor methods to >>>> Boolean. >>>> >>>> http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201 >>>> >>>> Thanks >> > From forax at univ-mlv.fr Thu Dec 6 10:47:46 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 06 Dec 2012 19:47:46 +0100 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50C0D75F.3030705@oracle.com> References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com> <50BFBC49.9020200@oracle.com> <50BFDC75.6000306@oracle.com> <50C0D75F.3030705@oracle.com> Message-ID: <50C0E852.7090109@univ-mlv.fr> On 12/06/2012 06:35 PM, Brian Goetz wrote: > This suggestion makes me nervous, because we're already asking a great > deal of type inference. If you say > > reduce(Operators::plus) > > and there are eight versions of Operators to choose from (and add > boxing into the mix), I think we'll see a lot more inference errors. > If the user says Integer::plus, the user has already told us what we > want, and we're done. I think that rule for method references are strong enough (unlike lambda you don't have to guess the type of the formal parameter) to work here, but we should not play with the devil. R?mi > > On 12/5/2012 6:44 PM, Joseph Darcy wrote: >> Akhil, >> >> In javadoc like this >> >> 298 * as {@code BinaryOperator<Boolean>}. >> >> you don't have to use "<" and the like inside {@code}; please >> change to >> >> 298 * as {@code BinaryOperator}. >> >> As a general comment, if the operations for primitive type Foo are put >> into java.lang.Foo, then the type of the operation needs to be >> explicitly represented in the expression calling the method (unless >> static imports are used, etc.). Therefore, I suggest putting these sort >> of static methods all into one class to allow overloading to do its >> thing (java.lang.Operators?). Also, for methods like sum, I think it is >> worth considering returning a larger type than the operands to avoid >> problems from integer or floating-point overflow. For example, sum on >> byte and short would return int, sun on int would return long, etc. >> >> As an aside, to get a numerically robust result, the summation logic >> over a set of doubles needs to be more than just a set of raw double >> additions, but that can be tackled later. >> >> Cheers, >> >> -Joe >> >> >> On 12/5/2012 1:27 PM, Akhil Arora wrote: >>> Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/ >>> >>> - delegate to Math.min/max for int/long/float/double >>> - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor >>> - removed Character variants of min/max/sum >>> >>> On 12/02/2012 05:50 PM, David Holmes wrote: >>>> Hi Akhil, >>>> >>>> Is it really necessary/desirable to flag all of these as " Suitable >>>> for >>>> conversion as a method reference to functional interfaces such as >>>> ..." ? >>> Not necessary, but it does provide a hint as to their intended use to a >>> casual browser of these docs. >>> >>>> This style: >>>> >>>> + * @param a a boolean argument. >>>> + * @param b another boolean argument. >>>> >>>> is at odds with the style used elsewhere for new Functional APIs, and >>>> with the style of other methods in these classes. Can we just use >>>> "first >>>> operand" and "second operand" for all of these? >>> It is consistent with Math.min/max, which use the a/b style. Since >>> these >>> methods are not in one of the functional package, is'nt it better to >>> stick to the local style? >>> >>>> Character.sum does not make sense to me. Who adds together characters? >>>> I'm not even sure min and max are worth supporting for Character. >>> Good point - removed these methods for Character. >>> >>>> I disagree with other suggestions to use the Math functions for >>>> float/double. I think all these methods should use the underlying >>>> primitive operator regardless of type. >>> Are you disagreeing only for float/double or for int/long also? Can you >>> provide more information as to why you disagree? >>> >>> Thanks >>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> On 1/12/2012 4:44 AM, Akhil Arora wrote: >>>>> Hi >>>>> >>>>> Requesting review for some basic functionality related to lambdas - >>>>> >>>>> Add min, max, sum methods to the primitive wrapper classes - Byte, >>>>> Short, Integer, Long, Float, Double and Character so as to be able to >>>>> use them as reducers in lambda expressions. Add and, or, xor >>>>> methods to >>>>> Boolean. >>>>> >>>>> http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201 >>>>> >>>>> Thanks >>> >> From c.mallwitz at gmail.com Thu Dec 6 11:30:24 2012 From: c.mallwitz at gmail.com (Christian Mallwitz) Date: Thu, 6 Dec 2012 19:30:24 +0000 Subject: Selecting a specific comparator method when sorting Message-ID: Hi I have been experimenting with some lambda sorting examples. Examples: List list = new ArrayList<>(); list.add("496"); list.add("6"); list.add("8128"); list.add("28"); list.add("33550336"); list .stream() .sorted(Comparators.comparing((IntFunction) Integer::parseInt)) // (1) .sorted(Comparators.comparing(Integer::parseInt)) // (2) .forEach(x -> { System.out.println(x); }); I understand in case (1) syntactically speaking the (IntFunction) part is just a type cast. What is the name and specification for the bit in (2)? Could you point me to the relevant Java spec parts? Additionally I want to share my attempt at a Schwartz Transformation - I have two versions: one version (A) requiring an additional class and one version (B) emitting a warning due to a type cast (which should be safe). Which one would you prefer? Any other feedback? Call as in: schwartz(list.stream(), Integer::parseInt).forEach(x -> { System.out.println(x); }); A) public static> Stream schwartz(Stream stream, Function f) { // class Pair - type of second element of pair must be Comparable final class Pair> { public final F first; public final S second; public Pair(F first, S second){ this.first = first; this.second = second; } } return stream .map(t -> new Pair<>(t, f.apply(t))) .sorted((p1, p2) -> p1.second.compareTo(p2.second)) .map(p -> p.first); } B) @SuppressWarnings("unchecked") public static> Stream schwartz(Stream stream, Function f) { return stream .map(t -> new Object[]{t, f.apply(t)}) .sorted((o1, o2) -> ((Comparable) o1[1]).compareTo(o2[1])) .map(o -> ((T) o[0])); } Cheers Christian From forax at univ-mlv.fr Thu Dec 6 12:45:43 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 06 Dec 2012 21:45:43 +0100 Subject: Selecting a specific comparator method when sorting In-Reply-To: References: Message-ID: <50C103F7.8070403@univ-mlv.fr> On 12/06/2012 08:30 PM, Christian Mallwitz wrote: > Hi > > I have been experimenting with some lambda sorting examples. Examples: > > List list = new ArrayList<>(); > list.add("496"); > list.add("6"); > list.add("8128"); > list.add("28"); > list.add("33550336"); > > list > .stream() > > .sorted(Comparators.comparing((IntFunction) > Integer::parseInt)) // (1) > .sorted(Comparators.comparing(Integer::parseInt)) // (2) > > .forEach(x -> { System.out.println(x); }); > > I understand in case (1) syntactically speaking the > (IntFunction) part is just a type cast. What is the name and > specification for the bit in (2)? Could you point me to the > relevant Java spec parts? is the type argument. when you call Comparators.comparing, you let the compiler figure by itself what is the type argument, it's you case 1, the argument of comparing is IntFunction so the compiler infers that the type argument, the T of Comparator comparing(IntFunction fun) is String. In case 2 you specify the type argument. Java spec: http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12.2 (the third phase) > > Additionally I want to share my attempt at a Schwartz Transformation - > I have two versions: one version (A) requiring an additional class and > one version (B) emitting a warning due to a type cast (which should be > safe). Which one would you prefer? Any other feedback? > > Call as in: > > schwartz(list.stream(), Integer::parseInt).forEach(x -> { > System.out.println(x); }); > > A) > > public static> Stream > schwartz(Stream stream, Function f) { > > // class Pair - type of second element of pair must be Comparable > final class Pair> { > public final F first; > public final S second; > public Pair(F first, S second){ this.first = first; > this.second = second; } > } > > return stream > .map(t -> new Pair<>(t, f.apply(t))) > .sorted((p1, p2) -> p1.second.compareTo(p2.second)) > .map(p -> p.first); > } > > B) > > @SuppressWarnings("unchecked") > public static> Stream > schwartz(Stream stream, Function f) { > > return stream > .map(t -> new Object[]{t, f.apply(t)}) > .sorted((o1, o2) -> ((Comparable) o1[1]).compareTo(o2[1])) > .map(o -> ((T) o[0])); > } A is better IMO, note that you can also create a class Lazy that is Comparable and map from t to Lazy, sort the Lazy and go back to t. > > Cheers > Christian > cheers, R?mi From marc at petit-huguenin.org Thu Dec 6 13:03:08 2012 From: marc at petit-huguenin.org (Marc Petit-Huguenin) Date: Thu, 06 Dec 2012 13:03:08 -0800 Subject: Selecting a specific comparator method when sorting In-Reply-To: References: Message-ID: <50C1080C.5030701@petit-huguenin.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12/06/2012 11:30 AM, Christian Mallwitz wrote: > Hi > > I have been experimenting with some lambda sorting examples. Examples: > > List list = new ArrayList<>(); list.add("496"); list.add("6"); > list.add("8128"); list.add("28"); list.add("33550336"); > > list .stream() > > .sorted(Comparators.comparing((IntFunction) Integer::parseInt)) // > (1) .sorted(Comparators.comparing(Integer::parseInt)) // (2) > > .forEach(x -> { System.out.println(x); }); > > I understand in case (1) syntactically speaking the (IntFunction) > part is just a type cast. What is the name and specification for the > bit in (2)? Could you point me to the relevant Java spec parts? > > Additionally I want to share my attempt at a Schwartz Transformation - I > have two versions: one version (A) requiring an additional class and one > version (B) emitting a warning due to a type cast (which should be safe). > Which one would you prefer? Any other feedback? > > Call as in: > > schwartz(list.stream(), Integer::parseInt).forEach(x -> { > System.out.println(x); }); > > A) > > public static> Stream > schwartz(Stream stream, Function f) { > > // class Pair - type of second element of pair must be Comparable final > class Pair> { public final F first; > public final S second; public Pair(F first, S second){ this.first = first; > this.second = second; } } > > return stream .map(t -> new Pair<>(t, f.apply(t))) .sorted((p1, p2) -> > p1.second.compareTo(p2.second)) .map(p -> p.first); } > > B) > > @SuppressWarnings("unchecked") public static super R>> Stream schwartz(Stream stream, Function f) { > > return stream .map(t -> new Object[]{t, f.apply(t)}) .sorted((o1, o2) -> > ((Comparable) o1[1]).compareTo(o2[1])) .map(o -> ((T) o[0])); } > If we still had MapStream: public static> Stream schwartz(Stream stream, Mapper f) { return stream.mapped(f) .swap() .sorted((p1, p2) -> p1.compareTo(p2)) .values(); } - -- Marc Petit-Huguenin Email: marc at petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQwQgKAAoJECnERZXWan7EcTEQAJlBXNmKe/iin0LMoDWQE8ct 2E0GIfD2hVBNelXsUjipiC6pm9TNjI1pCxlz+1CqnhNZuLt/o3hm+FvoVbfQa7SP 4/EBL2gcY290+fWBbPbmJ69NwCZDGrLyEMfl9Ac+DrPzKyaN+d1ZzqtOF+FFL8+a 6IZcd2AjLvtDTpVs7yckJt7NuJ9YEn4cLWP1KEwz0+bGI1EoolP8v3GBCdnXfVfM X6isMNQ9lZEzyHD5/vmjjVdWfT5PdIxasmVe5pn4R5wu0EpunBvaDMzBEQGdwyVJ c/pPs+aWgj1rtd+8oO4lg/XNxNksRnAIvuWVH75sdYLJtRNaxoigDuqHf6JKzrtS DUg/RJAqRqNANAxJFcf/D+VWZW0+tmH3trL399BqiF1fiF2GxerJ8UmHAe7R1OnD 2ytsvyA7nY9S21vO3dDB7eKlvhhRqgmT2OshhgigRfhMlrTlYX1Nj349K2Dt4t7b SjDx7G8VkFRP1YxRlJhfxURr+96/0Zpse6nWboBhhqATPrBEzzevCj+FKJ/+s6fQ E6b8GZ1VRrDwuii252v+XBMhOSkGpAJ8ujGAg+Xa6kGYtTsOSPU8aqyIUO+YSVTL RF8Iy+DRG6FZnI2i8dTQm1OCIJqeSlENEHH3RkTRsds+y55mfOBnhsJeiSJyFipM Ej4UcMVswcA0tAUZyddA =bh0J -----END PGP SIGNATURE----- From brian.goetz at oracle.com Thu Dec 6 13:07:11 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 06 Dec 2012 16:07:11 -0500 Subject: Selecting a specific comparator method when sorting In-Reply-To: References: Message-ID: <50C108FF.6050904@oracle.com> You shouldn't have to cast to IntFunction, but we're working on the overload resolution algorithm to make sure that works correctly. So you're really working around an issue with the interaction of type inference and overload resolution, which we're actively working on. On 12/6/2012 2:30 PM, Christian Mallwitz wrote: > Hi > > I have been experimenting with some lambda sorting examples. Examples: > > List list = new ArrayList<>(); > list.add("496"); > list.add("6"); > list.add("8128"); > list.add("28"); > list.add("33550336"); > > list > .stream() > > .sorted(Comparators.comparing((IntFunction) > Integer::parseInt)) // (1) > .sorted(Comparators.comparing(Integer::parseInt)) // (2) > > .forEach(x -> { System.out.println(x); }); > > I understand in case (1) syntactically speaking the > (IntFunction) part is just a type cast. What is the name and > specification for the bit in (2)? Could you point me to the > relevant Java spec parts? > > Additionally I want to share my attempt at a Schwartz Transformation - > I have two versions: one version (A) requiring an additional class and > one version (B) emitting a warning due to a type cast (which should be > safe). Which one would you prefer? Any other feedback? > > Call as in: > > schwartz(list.stream(), Integer::parseInt).forEach(x -> { > System.out.println(x); }); > > A) > > public static> Stream > schwartz(Stream stream, Function f) { > > // class Pair - type of second element of pair must be Comparable > final class Pair> { > public final F first; > public final S second; > public Pair(F first, S second){ this.first = first; > this.second = second; } > } > > return stream > .map(t -> new Pair<>(t, f.apply(t))) > .sorted((p1, p2) -> p1.second.compareTo(p2.second)) > .map(p -> p.first); > } > > B) > > @SuppressWarnings("unchecked") > public static> Stream > schwartz(Stream stream, Function f) { > > return stream > .map(t -> new Object[]{t, f.apply(t)}) > .sorted((o1, o2) -> ((Comparable) o1[1]).compareTo(o2[1])) > .map(o -> ((T) o[0])); > } > > Cheers > Christian > From david.holmes at oracle.com Thu Dec 6 18:02:34 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 07 Dec 2012 12:02:34 +1000 Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> <50C035F5.4050007@oracle.com> <50C093D2.3090909@oracle.com> <7DC6E3DE-9C1A-4DC6-8B26-E385C7882F44@oracle.com> Message-ID: <50C14E3A.7080907@oracle.com> Joe, On 7/12/2012 2:18 AM, Joe Bowbeer wrote: > The documentation for Collection.add is not a reasonable model to emulate? > > http://docs.oracle.com/javase/6/docs/api/java/util/Collection.html#add(E) > > It is written from the standpoint that nulls are OK, but notes that some > implementations might barf, and lists NPE among the possible exceptions. The difference here is that the intent is for nulls to be prohibited - full stop. In other places "we" avoid the API clutter by making broad statements regarding null handling "Unless otherwise stated null parameters to method or constructors of this class will result in NullPointerException being thrown". In some places we even handle this at the package doc level. Perhaps we should do the same here? Otherwise, the "right way" IMHO to indicate this is via @throws, not additional commentary on @param. Again YMMV. David ----- > I think that's the right approach for streams as well. > > In a wide range of popular APIs, there are lots of methods that return > null, and it is these nulls that are the most likely to show up in > functionally-constructed streams. Java programmers do have the notion that > nulls might not be allowed everywhere, and will look to the javadoc for > clarification. > > > > On Thu, Dec 6, 2012 at 7:56 AM, Mike Duigou wrote: > >> Something seems entirely out of balance regarding handling of null. If a >> methods says that it takes a reference type then why ever might it be >> assumed that null is permitted? >> >> It feels more than a bit like we are adding "no naked people" stickers to >> every building entrance and "do not insert fingers" to every electrical >> outlet. The "@throws NPE" are yet another layer of "Violators will be >> arrested" or "You will be electrocuted" stickers. >> >> It seems entirely wrongheaded to assume that null could be passed in place >> of a valid reference unless explicitly and categorically forbidden. >> Accepting null should be considered extraordinary and worthy of mention >> only when it occurs. Being rare it would also be a lot easier to document. >> >> So really, why mention null at all? >> >> Mike >> >> On Dec 6 2012, at 04:47 , David Holmes wrote: >> >>> Stephen, >>> >>> I believe that exceptions thrown should be identified using @throws - >> not implied. >>> >>> I think @param is for giving the basic description of a parameter not >> for explaining the semantics, or what different values of the parameter >> mean. >>> >>> YMMV >>> >>> David >>> >>> On 6/12/2012 8:23 PM, Stephen Colebourne wrote: >>>> On 6 December 2012 06:06, David Holmes wrote: >>>>> On 6/12/2012 4:20 AM, Mike Duigou wrote: >>>>>> >>>>>> I have updated webrev again to fix some reported javadoc technical >> issues >>>>>> and added null handling specification to the >> {Int|Double|Long}Supplier. >>>>>> >>>>>> http://cr.openjdk.java.net/~mduigou/8004015/2/webrev/ >>>>>> >>>>>> >> http://cr.openjdk.java.net/~mduigou/8004015/2/specdiff/java/util/function/package-summary.html >>>>>> >>>>>> I believe that this iteration is complete (or very nearly so). >>>>> >>>>> Sorry to be a pain but this: >>>>> >>>>> left - the left operand, must be non-null >>>>> >>>>> doesn't tell you what happens if it is null. Is it not better to simply >>>>> have: >>>>> >>>>> @param left the left operand >>>>> @param right the right operand >>>>> @throws NullPointerException if either left or right are null >>>> >>>> Whereas I use: >>>> @param left the left operand, not null >>>> @param right the right operand, not null >>>> >>>> There is an element of taste here. As I wrote up >>>> http://blog.joda.org/2012/11/javadoc-coding-standards.html >>>> Javadoc is read as source code as often as it is read as HTML. Thus, >>>> not overly cluttering is important. >>>> IMO, the @throws NPE is implied by the assertion of "not null" or >>>> "must be non-null". >>>> >>>> More importantly, the use of @param scales better. For example, there >>>> is often a case where null is treated as a default or special value. >>>> The Javadoc would then look something like >>>> >>>> @param left the left operand, null treated as zero >>>> @param right the right operand, null treated as zero >>>> >>>> This kind of information belongs with the @param, and for consistency >>>> it is much better to also have the "not null" aspect on the @param as >>>> well. (Everything together is easier for developers to parse) >>>> >>>> In summary, while I prefer my "not null" to Mike's "must be non-null", >>>> what is proposed is fine, and better than your (David's) proposal. >>>> >>>> Stephen >>>> >> >> > From joe.bowbeer at gmail.com Thu Dec 6 19:45:48 2012 From: joe.bowbeer at gmail.com (Joe Bowbeer) Date: Thu, 6 Dec 2012 19:45:48 -0800 Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: <50C14E3A.7080907@oracle.com> References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> <50C035F5.4050007@oracle.com> <50C093D2.3090909@oracle.com> <7DC6E3DE-9C1A-4DC6-8B26-E385C7882F44@oracle.com> <50C14E3A.7080907@oracle.com> Message-ID: Ah, yes, I misunderstood the intent. Sorry. I agree that the null wording should be minimized, esp. in the parameter descriptions. The @throws NPE descriptions make it clear in every occurrence that nulls are prevented, which I like in this case, but do not distract the casual reader. On Thu, Dec 6, 2012 at 6:02 PM, David Holmes wrote: > Joe, > > > On 7/12/2012 2:18 AM, Joe Bowbeer wrote: > >> The documentation for Collection.add is not a reasonable model to emulate? >> >> http://docs.oracle.com/javase/**6/docs/api/java/util/** >> Collection.html#add(E) >> >> It is written from the standpoint that nulls are OK, but notes that some >> implementations might barf, and lists NPE among the possible exceptions. >> > > The difference here is that the intent is for nulls to be prohibited - > full stop. > > In other places "we" avoid the API clutter by making broad statements > regarding null handling "Unless otherwise stated null parameters to method > or constructors of this class will result in NullPointerException being > thrown". In some places we even handle this at the package doc level. > Perhaps we should do the same here? > > Otherwise, the "right way" IMHO to indicate this is via @throws, not > additional commentary on @param. > > Again YMMV. > > David > ----- > > > I think that's the right approach for streams as well. >> >> In a wide range of popular APIs, there are lots of methods that return >> null, and it is these nulls that are the most likely to show up in >> functionally-constructed streams. Java programmers do have the notion >> that >> nulls might not be allowed everywhere, and will look to the javadoc for >> clarification. >> >> >> >> On Thu, Dec 6, 2012 at 7:56 AM, Mike Duigou >> wrote: >> >> Something seems entirely out of balance regarding handling of null. If a >>> methods says that it takes a reference type then why ever might it be >>> assumed that null is permitted? >>> >>> It feels more than a bit like we are adding "no naked people" stickers to >>> every building entrance and "do not insert fingers" to every electrical >>> outlet. The "@throws NPE" are yet another layer of "Violators will be >>> arrested" or "You will be electrocuted" stickers. >>> >>> It seems entirely wrongheaded to assume that null could be passed in >>> place >>> of a valid reference unless explicitly and categorically forbidden. >>> Accepting null should be considered extraordinary and worthy of mention >>> only when it occurs. Being rare it would also be a lot easier to >>> document. >>> >>> So really, why mention null at all? >>> >>> Mike >>> >>> On Dec 6 2012, at 04:47 , David Holmes wrote: >>> >>> Stephen, >>>> >>>> I believe that exceptions thrown should be identified using @throws - >>>> >>> not implied. >>> >>>> >>>> I think @param is for giving the basic description of a parameter not >>>> >>> for explaining the semantics, or what different values of the parameter >>> mean. >>> >>>> >>>> YMMV >>>> >>>> David >>>> >>>> On 6/12/2012 8:23 PM, Stephen Colebourne wrote: >>>> >>>>> On 6 December 2012 06:06, David Holmes >>>>> wrote: >>>>> >>>>>> On 6/12/2012 4:20 AM, Mike Duigou wrote: >>>>>> >>>>>>> >>>>>>> I have updated webrev again to fix some reported javadoc technical >>>>>>> >>>>>> issues >>> >>>> and added null handling specification to the >>>>>>> >>>>>> {Int|Double|Long}Supplier. >>> >>>> >>>>>>> http://cr.openjdk.java.net/~**mduigou/8004015/2/webrev/ >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~**mduigou/8004015/2/specdiff/** >>> java/util/function/package-**summary.html >>> >>>> >>>>>>> I believe that this iteration is complete (or very nearly so). >>>>>>> >>>>>> >>>>>> Sorry to be a pain but this: >>>>>> >>>>>> left - the left operand, must be non-null >>>>>> >>>>>> doesn't tell you what happens if it is null. Is it not better to >>>>>> simply >>>>>> have: >>>>>> >>>>>> @param left the left operand >>>>>> @param right the right operand >>>>>> @throws NullPointerException if either left or right are null >>>>>> >>>>> >>>>> Whereas I use: >>>>> @param left the left operand, not null >>>>> @param right the right operand, not null >>>>> >>>>> There is an element of taste here. As I wrote up >>>>> http://blog.joda.org/2012/11/**javadoc-coding-standards.html >>>>> Javadoc is read as source code as often as it is read as HTML. Thus, >>>>> not overly cluttering is important. >>>>> IMO, the @throws NPE is implied by the assertion of "not null" or >>>>> "must be non-null". >>>>> >>>>> More importantly, the use of @param scales better. For example, there >>>>> is often a case where null is treated as a default or special value. >>>>> The Javadoc would then look something like >>>>> >>>>> @param left the left operand, null treated as zero >>>>> @param right the right operand, null treated as zero >>>>> >>>>> This kind of information belongs with the @param, and for consistency >>>>> it is much better to also have the "not null" aspect on the @param as >>>>> well. (Everything together is easier for developers to parse) >>>>> >>>>> In summary, while I prefer my "not null" to Mike's "must be non-null", >>>>> what is proposed is fine, and better than your (David's) proposal. >>>>> >>>>> Stephen >>>>> >>>>> >>> >>> >> From robert.field at oracle.com Thu Dec 6 20:11:51 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 07 Dec 2012 04:11:51 +0000 Subject: hg: lambda/lambda/jdk: 8003881: Prevent lambda implementing inner classes from allowing the creation of new instances Message-ID: <20121207041212.6D8F247F7F@hg.openjdk.java.net> Changeset: 7063c85474d3 Author: rfield Date: 2012-12-06 20:11 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7063c85474d3 8003881: Prevent lambda implementing inner classes from allowing the creation of new instances Summary: Lambda implementing inner classes now has private constructor (thanks Kumar) Reviewed-by: ksrini + test/java/lang/invoke/lambda/LambdaAccessControlDoPrivilegedTest.java + test/java/lang/invoke/lambda/LambdaAccessControlTest.java From david.holmes at oracle.com Thu Dec 6 23:03:06 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 07 Dec 2012 17:03:06 +1000 Subject: Request for Review: CR#8001667, second attempt In-Reply-To: References: <50C041D3.9060703@oracle.com> Message-ID: <50C194AA.20507@oracle.com> On 6/12/2012 8:29 PM, Stephen Colebourne wrote: > On 6 December 2012 06:57, Henry Jen wrote: >> Please review and comment on the webrev[1] and specdiff[2]. >> >> [1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.1/webrev >> [2] >> http://cr.openjdk.java.net/~henryjen/ccc/8001667.1/specdiff/overview-summary.html > > Are you allowed to change the copyright date? Allowed and ultimately required. > I also note that the generic catch-all null statement at the class > level is less usable than a "not null" or "must be non-null" on each > @param. But is the existing practice in j.u David ----- > Stephen > From paul.sandoz at oracle.com Fri Dec 7 00:59:37 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 07 Dec 2012 08:59:37 +0000 Subject: hg: lambda/lambda/jdk: - cumulate for int streams. Message-ID: <20121207085958.DD88347FAB@hg.openjdk.java.net> Changeset: d07b0d36be54 Author: psandoz Date: 2012-12-07 09:57 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d07b0d36be54 - cumulate for int streams. ! src/share/classes/java/util/stream/op/CumulateOp.java + src/share/classes/java/util/stream/primitive/IntCumulateOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntSpinedBuffer.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/CumulateOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntCumulateOpTest.java From peter.levart at gmail.com Fri Dec 7 01:09:18 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 07 Dec 2012 10:09:18 +0100 Subject: Request for Review: CR#8001667, second attempt In-Reply-To: <50C041D3.9060703@oracle.com> References: <50C041D3.9060703@oracle.com> Message-ID: <50C1B23E.8010003@gmail.com> Hi Henry, I don't know what the plans are about moving the static methods in Comparators to the Comparator interface when static interface methods are enabled, but if that is planned, there will be a clash between Comparator.reverseOrder() default method and static method with same name and signature. Maybe rename static .reverseOrder() to .reverseNaturalOrder() (to long?), or rename the default method .reverseOrder() to .reverse(); Also, I like the natural-language-like fluent syntax when starting with Comparators.comparing(...).thenComparing(...).reverse[Order](), but the .thenComparing name is also overloaded with the variant for composing: .thenComparing(Comparator) which makes statements like: Comparators.comparing(x -> x.size).thenComparing(x -> x.y).thenComparing((x, y) -> some expression) a little confusing, because what you get is not a comparator that compares one value of "some expression" with some other value of the same expression, but a comparator that uses the value of expression to order two elements. I think that using the same method name for two different purposes is a little confusing. Maybe .compose(Comparator) or just plain .then(Comparator) would be better here. Regards, Peter On 12/06/2012 07:57 AM, Henry Jen wrote: > Hi, > > This update reflect changes based on feedbacks for last version, the > changes are > > - rename reverse() to reverseOrder() > - rename Comparator.compose to Comparator.thenComparing > - add 4 Comparator.thenComparing methods take [Int|Long|Double]Function > to enable fluent syntax like this example, > > people.sort(Comparators.comparing(People::getFirstName).thenComparing(People.getLastName)) > > vs previously, > > people.sort(Comparators.comparing(Person::getName)) > Comparator byLastFirst > = Comparators.comparing(Person::getLastName) > .compose(Comparators.comparing(Person::getFirstName)) > > Please review and comment on the webrev[1] and specdiff[2]. > > [1] http://cr.openjdk.java.net/~henryjen/ccc/8001667.1/webrev > [2] > http://cr.openjdk.java.net/~henryjen/ccc/8001667.1/specdiff/overview-summary.html > > Cheers, > Henry From paul.sandoz at oracle.com Fri Dec 7 01:31:09 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 07 Dec 2012 09:31:09 +0000 Subject: hg: lambda/lambda/jdk: - flat map for int streams Message-ID: <20121207093122.DC64647FAC@hg.openjdk.java.net> Changeset: b9ddec25f9ea Author: psandoz Date: 2012-12-07 10:30 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b9ddec25f9ea - flat map for int streams - flat map operations should preserve encounter order e.g flatmap can be used like "mapcat" to map an element to a collection and then put all elements of the collection into the stream ! src/share/classes/java/util/stream/op/FlatMapOp.java + src/share/classes/java/util/stream/primitive/IntFlatMapOp.java + src/share/classes/java/util/stream/primitive/IntFlatMapper.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java ! src/share/classes/java/util/stream/primitive/IntStream.java + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntFlatMapOpTest.java From henry.jen at oracle.com Fri Dec 7 09:27:02 2012 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 7 Dec 2012 09:27:02 -0800 Subject: Request for Review: CR#8001667, second attempt In-Reply-To: <50C1B23E.8010003@gmail.com> References: <50C041D3.9060703@oracle.com> <50C1B23E.8010003@gmail.com> Message-ID: <32DA82DE-9FFF-4ABA-BD38-480057EADE7A@oracle.com> On Dec 7, 2012, at 1:09 AM, Peter Levart wrote: > Hi Henry, > > I don't know what the plans are about moving the static methods in Comparators to the Comparator interface when static interface methods are enabled, but if that is planned, there will be a clash between Comparator.reverseOrder() default method and static method with same name and signature. > We will be exploring that along with other classes given static default method support ready. Cheers, Henry From maurizio.cimadamore at oracle.com Fri Dec 7 11:25:01 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 07 Dec 2012 19:25:01 +0000 Subject: hg: lambda/lambda/langtools: 24 new changesets Message-ID: <20121207192555.92FCD47FC0@hg.openjdk.java.net> Changeset: e6b1abdc11ca Author: rfield Date: 2012-11-13 08:06 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e6b1abdc11ca 8003306: Compiler crash: calculation of inner class access modifier Summary: Fix binary sense lost in transition to hasTag Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/InnerConstructor.java Changeset: 2901c7b5339e Author: jjg Date: 2012-11-13 15:09 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2901c7b5339e 8003299: Cleanup javac Log support for deferred diagnostics Reviewed-by: mcimadamore, jfranck ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Log.java Changeset: f14c693a0e48 Author: jjg Date: 2012-11-14 10:07 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/f14c693a0e48 8003412: javac needs to understand java.lang.annotation.Native Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! test/tools/javac/nativeHeaders/NativeHeaderTest.java ! test/tools/javac/nativeHeaders/javahComparison/CompareTest.java + test/tools/javac/nativeHeaders/javahComparison/TestClass4.java + test/tools/javac/nativeHeaders/javahComparison/TestClass5.java Changeset: b486794d160d Author: lana Date: 2012-11-14 16:41 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/b486794d160d Merge Changeset: 33abf479f202 Author: jjg Date: 2012-11-14 17:23 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/33abf479f202 7021614: extend com.sun.source API to support parsing javadoc comments Reviewed-by: ksrini, strarup ! make/build.xml + src/share/classes/com/sun/source/doctree/AttributeTree.java + src/share/classes/com/sun/source/doctree/AuthorTree.java + src/share/classes/com/sun/source/doctree/BlockTagTree.java + src/share/classes/com/sun/source/doctree/CommentTree.java + src/share/classes/com/sun/source/doctree/DeprecatedTree.java + src/share/classes/com/sun/source/doctree/DocCommentTree.java + src/share/classes/com/sun/source/doctree/DocRootTree.java + src/share/classes/com/sun/source/doctree/DocTree.java + src/share/classes/com/sun/source/doctree/DocTreeVisitor.java + src/share/classes/com/sun/source/doctree/EndElementTree.java + src/share/classes/com/sun/source/doctree/EntityTree.java + src/share/classes/com/sun/source/doctree/ErroneousTree.java + src/share/classes/com/sun/source/doctree/IdentifierTree.java + src/share/classes/com/sun/source/doctree/InheritDocTree.java + src/share/classes/com/sun/source/doctree/InlineTagTree.java + src/share/classes/com/sun/source/doctree/LinkTree.java + src/share/classes/com/sun/source/doctree/LiteralTree.java + src/share/classes/com/sun/source/doctree/ParamTree.java + src/share/classes/com/sun/source/doctree/ReferenceTree.java + src/share/classes/com/sun/source/doctree/ReturnTree.java + src/share/classes/com/sun/source/doctree/SeeTree.java + src/share/classes/com/sun/source/doctree/SerialDataTree.java + src/share/classes/com/sun/source/doctree/SerialFieldTree.java + src/share/classes/com/sun/source/doctree/SerialTree.java + src/share/classes/com/sun/source/doctree/SinceTree.java + src/share/classes/com/sun/source/doctree/StartElementTree.java + src/share/classes/com/sun/source/doctree/TextTree.java + src/share/classes/com/sun/source/doctree/ThrowsTree.java + src/share/classes/com/sun/source/doctree/UnknownBlockTagTree.java + src/share/classes/com/sun/source/doctree/UnknownInlineTagTree.java + src/share/classes/com/sun/source/doctree/ValueTree.java + src/share/classes/com/sun/source/doctree/VersionTree.java + src/share/classes/com/sun/source/doctree/package-info.java ! src/share/classes/com/sun/source/tree/Tree.java + src/share/classes/com/sun/source/util/DocTreeScanner.java + src/share/classes/com/sun/source/util/DocTrees.java + src/share/classes/com/sun/source/util/SimpleDocTreeVisitor.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Env.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java + src/share/classes/com/sun/tools/javac/parser/LazyDocCommentTable.java ! src/share/classes/com/sun/tools/javac/parser/ParserFactory.java - src/share/classes/com/sun/tools/javac/parser/SimpleDocCommentTable.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + src/share/classes/com/sun/tools/javac/tree/DCTree.java ! src/share/classes/com/sun/tools/javac/tree/DocCommentTable.java + src/share/classes/com/sun/tools/javac/tree/DocPretty.java + src/share/classes/com/sun/tools/javac/tree/DocTreeMaker.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java ! test/tools/javac/diags/CheckExamples.java + test/tools/javac/diags/DocCommentProcessor.java ! test/tools/javac/diags/Example.java ! test/tools/javac/diags/RunExamples.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/BadEntity.java + test/tools/javac/diags/examples/BadGreaterThan.java + test/tools/javac/diags/examples/BadInlineTag.java + test/tools/javac/diags/examples/GreaterThanExpected.java + test/tools/javac/diags/examples/MalformedHTML.java + test/tools/javac/diags/examples/MissingSemicolon.java + test/tools/javac/diags/examples/NoTagName.java + test/tools/javac/diags/examples/RefBadParens.java + test/tools/javac/diags/examples/RefIdentifierExpected.java + test/tools/javac/diags/examples/RefSyntaxError.java + test/tools/javac/diags/examples/RefUnexpectedInput.java + test/tools/javac/diags/examples/UnexpectedContent.java + test/tools/javac/diags/examples/UnterminatedInlineTag.java + test/tools/javac/diags/examples/UnterminatedSignature.java + test/tools/javac/doctree/AttrTest.java + test/tools/javac/doctree/AuthorTest.java + test/tools/javac/doctree/BadTest.java + test/tools/javac/doctree/CodeTest.java + test/tools/javac/doctree/DeprecatedTest.java + test/tools/javac/doctree/DocCommentTester.java + test/tools/javac/doctree/DocRootTest.java + test/tools/javac/doctree/ElementTest.java + test/tools/javac/doctree/EntityTest.java + test/tools/javac/doctree/ExceptionTest.java + test/tools/javac/doctree/FirstSentenceTest.java + test/tools/javac/doctree/InheritDocTest.java + test/tools/javac/doctree/LinkPlainTest.java + test/tools/javac/doctree/LinkTest.java + test/tools/javac/doctree/LiteralTest.java + test/tools/javac/doctree/ParamTest.java + test/tools/javac/doctree/ReferenceTest.java + test/tools/javac/doctree/ReturnTest.java + test/tools/javac/doctree/SeeTest.java + test/tools/javac/doctree/SerialDataTest.java + test/tools/javac/doctree/SerialFieldTest.java + test/tools/javac/doctree/SerialTest.java + test/tools/javac/doctree/SimpleDocTreeVisitorTest.java + test/tools/javac/doctree/SinceTest.java + test/tools/javac/doctree/TagTest.java + test/tools/javac/doctree/ThrowableTest.java + test/tools/javac/doctree/ValueTest.java + test/tools/javac/doctree/VersionTest.java Changeset: bfec2a1cc869 Author: jjg Date: 2012-11-15 09:18 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/bfec2a1cc869 8000800: javadoc uses static non-final fields Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/WriterFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AbstractDoclet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/BuilderFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/InheritDocTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javadoc/ParamTagImpl.java ! test/com/sun/javadoc/MetaTag/MetaTag.java ! test/com/sun/javadoc/testHtmlDocument/TestHtmlDocument.java Changeset: 467f4f754368 Author: jjg Date: 2012-11-15 14:41 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/467f4f754368 8003257: refactor javadoc tool option handling Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocLocale.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/Start.java + src/share/classes/com/sun/tools/javadoc/ToolOption.java Changeset: 400a4e8accd3 Author: jjg Date: 2012-11-15 19:54 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/400a4e8accd3 8002079: update DocFile to use a JavaFileManager Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPath.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java Changeset: bdcef2ef52d2 Author: jjg Date: 2012-11-15 23:07 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/bdcef2ef52d2 6493690: javadoc should have a javax.tools.Tool service provider installed in tools.jar Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/TagletManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Extern.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/share/classes/com/sun/tools/javac/api/ClientCodeWrapper.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/Start.java + src/share/classes/com/sun/tools/javadoc/api/JavadocTaskImpl.java + src/share/classes/com/sun/tools/javadoc/api/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties + src/share/classes/javax/tools/DocumentationTool.java ! src/share/classes/javax/tools/JavaCompiler.java ! src/share/classes/javax/tools/ToolProvider.java ! test/tools/javadoc/CheckResourceKeys.java + test/tools/javadoc/api/basic/APITest.java + test/tools/javadoc/api/basic/DocletPathTest.java + test/tools/javadoc/api/basic/GetSourceVersionsTest.java + test/tools/javadoc/api/basic/GetTask_DiagListenerTest.java + test/tools/javadoc/api/basic/GetTask_DocletClassTest.java + test/tools/javadoc/api/basic/GetTask_FileManagerTest.java + test/tools/javadoc/api/basic/GetTask_FileObjectsTest.java + test/tools/javadoc/api/basic/GetTask_OptionsTest.java + test/tools/javadoc/api/basic/GetTask_WriterTest.java + test/tools/javadoc/api/basic/IsSupportedOptionTest.java + test/tools/javadoc/api/basic/JavadocTaskImplTest.java + test/tools/javadoc/api/basic/RunTest.java + test/tools/javadoc/api/basic/TagletPathTest.java + test/tools/javadoc/api/basic/Task_reuseTest.java + test/tools/javadoc/api/basic/pkg/C.java + test/tools/javadoc/api/basic/taglets/UnderlineTaglet.java Changeset: 843d3b191773 Author: jjh Date: 2012-11-16 18:27 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/843d3b191773 8003357: Add support for jtreg -concurrency to langtools/test/Makefile Reviewed-by: jjg ! test/Makefile Changeset: 01c9d4161882 Author: mcimadamore Date: 2012-11-17 19:01 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/01c9d4161882 8003280: Add lambda tests Summary: Turn on lambda expression, method reference and default method support Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symbol.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/DeferredAttr.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/Resolve.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/Pool.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Warner.java ! test/tools/javac/conditional/Conditional.java ! test/tools/javac/defaultMethods/ClassReaderTest/ClassReaderTest.java ! test/tools/javac/defaultMethods/Neg01.java ! test/tools/javac/defaultMethods/Neg02.java ! test/tools/javac/defaultMethods/Neg03.java ! test/tools/javac/defaultMethods/Neg04.java ! test/tools/javac/defaultMethods/Neg05.java ! test/tools/javac/defaultMethods/Neg06.java ! test/tools/javac/defaultMethods/Neg07.java ! test/tools/javac/defaultMethods/Neg08.java ! test/tools/javac/defaultMethods/Neg09.java ! test/tools/javac/defaultMethods/Neg10.java ! test/tools/javac/defaultMethods/Neg11.java ! test/tools/javac/defaultMethods/Neg12.java ! test/tools/javac/defaultMethods/Neg12.out ! test/tools/javac/defaultMethods/Neg13.java ! test/tools/javac/defaultMethods/Neg14.java ! test/tools/javac/defaultMethods/Neg15.java ! test/tools/javac/defaultMethods/Neg16.java ! test/tools/javac/defaultMethods/Pos01.java ! test/tools/javac/defaultMethods/Pos02.java ! test/tools/javac/defaultMethods/Pos04.java ! test/tools/javac/defaultMethods/Pos05.java ! test/tools/javac/defaultMethods/Pos06.java ! test/tools/javac/defaultMethods/Pos07.java ! test/tools/javac/defaultMethods/Pos08.java ! test/tools/javac/defaultMethods/Pos10.java ! test/tools/javac/defaultMethods/Pos11.java ! test/tools/javac/defaultMethods/Pos12.java ! test/tools/javac/defaultMethods/Pos13.java ! test/tools/javac/defaultMethods/Pos14.java ! test/tools/javac/defaultMethods/Pos15.java ! test/tools/javac/defaultMethods/Pos16.java ! test/tools/javac/defaultMethods/TestDefaultBody.java ! test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java ! test/tools/javac/defaultMethods/fd/FDTest.java ! test/tools/javac/defaultMethods/separate/Separate.java ! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java - test/tools/javac/diags/examples/CantAccessArgTypeInFunctionalDesc.java ! test/tools/javac/diags/examples/CantAccessInnerClsConstr.java - test/tools/javac/diags/examples/CantAccessReturnTypeInFunctionalDesc.java - test/tools/javac/diags/examples/CantAccessThrownTypesInFunctionalDesc.java ! test/tools/javac/diags/examples/CantApplySymbolFragment.java ! test/tools/javac/diags/examples/CantApplySymbolsFragment.java ! test/tools/javac/diags/examples/CantRefNonEffectivelyFinalVar.java ! test/tools/javac/diags/examples/CantResolveLocationArgsFragment.java ! test/tools/javac/diags/examples/CantResolveLocationArgsParamsFragment.java - test/tools/javac/diags/examples/CantReturnValueForVoid.java + test/tools/javac/diags/examples/ConditionalTargetCantBeVoid.java ! test/tools/javac/diags/examples/CyclicInference.java ! test/tools/javac/diags/examples/DefaultOverridesObjectMember.java ! test/tools/javac/diags/examples/IncompatibleAbstracts.java ! test/tools/javac/diags/examples/IncompatibleArgTypesInLambda.java ! test/tools/javac/diags/examples/IncompatibleDescsInFunctionalIntf.java ! test/tools/javac/diags/examples/IncompatibleRetTypeInLambda.java ! test/tools/javac/diags/examples/IncompatibleRetTypeInMref.java ! test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java ! test/tools/javac/diags/examples/IncompatibleThrownTypesInMref.java ! test/tools/javac/diags/examples/IncompatibleTypesInConditional.java ! test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java ! test/tools/javac/diags/examples/LocalVarNeedsFinal.java ! test/tools/javac/diags/examples/MissingReturnValue.java ! test/tools/javac/diags/examples/MissingReturnValueFragment.java ! test/tools/javac/diags/examples/NoAbstracts.java ! test/tools/javac/diags/examples/NoSuitableFunctionalIntfInst.java ! test/tools/javac/diags/examples/NonStaticCantBeRefFragment.java ! test/tools/javac/diags/examples/NotAFunctionalIntf.java ! test/tools/javac/diags/examples/NotDefAccessClassIntfCantAccessFragment.java ! test/tools/javac/diags/examples/OverriddenDefault.java ! test/tools/javac/diags/examples/PotentialLambdaFound.java ! test/tools/javac/diags/examples/RedundantSupertype.java ! test/tools/javac/diags/examples/RefAmbiguousFragment.java ! test/tools/javac/diags/examples/TypesIncompatibleAbstractDefault.java ! test/tools/javac/diags/examples/TypesIncompatibleUnrelatedDefaults.java ! test/tools/javac/diags/examples/UnexpectedLambda.java ! test/tools/javac/diags/examples/UnexpectedMref.java + test/tools/javac/diags/examples/UnexpectedReturnValue.java ! test/tools/javac/generics/7022054/T7022054pos1.java + test/tools/javac/generics/7022054/T7022054pos1.out ! test/tools/javac/generics/7022054/T7022054pos2.java + test/tools/javac/generics/7022054/T7022054pos2.out + test/tools/javac/lambda/BadAccess.java + test/tools/javac/lambda/BadAccess.out + test/tools/javac/lambda/BadAccess02.java + test/tools/javac/lambda/BadAccess02.out + test/tools/javac/lambda/BadAccess03.java + test/tools/javac/lambda/BadAccess03.out + test/tools/javac/lambda/BadBreakContinue.java + test/tools/javac/lambda/BadBreakContinue.out + test/tools/javac/lambda/BadConv03.java + test/tools/javac/lambda/BadConv03.out + test/tools/javac/lambda/BadConv04.java + test/tools/javac/lambda/BadConv04.out + test/tools/javac/lambda/BadExpressionLambda.java + test/tools/javac/lambda/BadExpressionLambda.out + test/tools/javac/lambda/BadLambdaExpr.java + test/tools/javac/lambda/BadLambdaPos.java + test/tools/javac/lambda/BadLambdaPos.out + test/tools/javac/lambda/BadMethodCall.java + test/tools/javac/lambda/BadMethodCall.out + test/tools/javac/lambda/BadRecovery.java + test/tools/javac/lambda/BadRecovery.out + test/tools/javac/lambda/BadReturn.java + test/tools/javac/lambda/BadReturn.out + test/tools/javac/lambda/BadStatementInLambda.java + test/tools/javac/lambda/BadStatementInLambda.out + test/tools/javac/lambda/BadStatementInLambda02.java + test/tools/javac/lambda/BadStatementInLambda02.out + test/tools/javac/lambda/BadTargetType.java + test/tools/javac/lambda/BadTargetType.out + test/tools/javac/lambda/Conditional01.java + test/tools/javac/lambda/Conditional02.java + test/tools/javac/lambda/Conditional03.java + test/tools/javac/lambda/Conformance01.java + test/tools/javac/lambda/Defender01.java + test/tools/javac/lambda/DisjunctiveTypeTest.java + test/tools/javac/lambda/EffectivelyFinal01.java + test/tools/javac/lambda/EffectivelyFinal01.out ! test/tools/javac/lambda/EffectivelyFinalTest.java ! test/tools/javac/lambda/EffectivelyFinalTest01.out ! test/tools/javac/lambda/EffectivelyFinalTest02.out + test/tools/javac/lambda/ErroneousArg.java + test/tools/javac/lambda/ErroneousArg.out + test/tools/javac/lambda/ErroneousLambdaExpr.java ! test/tools/javac/lambda/InnerConstructor.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/LambdaCapture06.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/LambdaConv09.out + test/tools/javac/lambda/LambdaConv10.java + test/tools/javac/lambda/LambdaConv10.out + test/tools/javac/lambda/LambdaConv11.java + test/tools/javac/lambda/LambdaConv12.java + test/tools/javac/lambda/LambdaConv13.java + test/tools/javac/lambda/LambdaConv16.java + test/tools/javac/lambda/LambdaConv17.java + test/tools/javac/lambda/LambdaConv18.java + test/tools/javac/lambda/LambdaConv18.out + test/tools/javac/lambda/LambdaConv19.java + test/tools/javac/lambda/LambdaConv20.java + test/tools/javac/lambda/LambdaConv21.java + test/tools/javac/lambda/LambdaConv21.out + test/tools/javac/lambda/LambdaConv22.java + test/tools/javac/lambda/LambdaConv23.java + test/tools/javac/lambda/LambdaConv24.java + test/tools/javac/lambda/LambdaConversionTest.java + test/tools/javac/lambda/LambdaEffectivelyFinalTest.java + test/tools/javac/lambda/LambdaEffectivelyFinalTest.out + 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/LambdaExpr06.java + test/tools/javac/lambda/LambdaExpr07.java + test/tools/javac/lambda/LambdaExpr08.java + test/tools/javac/lambda/LambdaExpr09.java + test/tools/javac/lambda/LambdaExpr10.java + test/tools/javac/lambda/LambdaExpr10.out + test/tools/javac/lambda/LambdaExpr11.java + test/tools/javac/lambda/LambdaExpr12.java + test/tools/javac/lambda/LambdaExpr13.java + test/tools/javac/lambda/LambdaExpr14.java + test/tools/javac/lambda/LambdaExpr15.java + test/tools/javac/lambda/LambdaExpr16.java + test/tools/javac/lambda/LambdaExpr17.java + test/tools/javac/lambda/LambdaExpr18.java + test/tools/javac/lambda/LambdaExpr19.java + test/tools/javac/lambda/LambdaExpr19.out + test/tools/javac/lambda/LambdaExpr20.java + test/tools/javac/lambda/LambdaExprNotVoid.java + test/tools/javac/lambda/LambdaExprNotVoid.out ! test/tools/javac/lambda/LambdaParserTest.java + test/tools/javac/lambda/LambdaScope01.java + test/tools/javac/lambda/LambdaScope02.java + test/tools/javac/lambda/LambdaScope03.java + test/tools/javac/lambda/LambdaScope04.java + test/tools/javac/lambda/LambdaScope04.out + 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/MethodReference04.out + 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/MethodReference08.out + test/tools/javac/lambda/MethodReference09.java + test/tools/javac/lambda/MethodReference09.out + 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/MethodReference20.out + test/tools/javac/lambda/MethodReference21.java + test/tools/javac/lambda/MethodReference21.out + test/tools/javac/lambda/MethodReference22.java + test/tools/javac/lambda/MethodReference22.out + test/tools/javac/lambda/MethodReference23.java + test/tools/javac/lambda/MethodReference23.out + test/tools/javac/lambda/MethodReference24.java + test/tools/javac/lambda/MethodReference25.java + test/tools/javac/lambda/MethodReference26.java + test/tools/javac/lambda/MethodReference26.out + test/tools/javac/lambda/MethodReference27.java + test/tools/javac/lambda/MethodReference28.java + test/tools/javac/lambda/MethodReference28.out + test/tools/javac/lambda/MethodReference29.java + test/tools/javac/lambda/MethodReference30.java + test/tools/javac/lambda/MethodReference31.java + test/tools/javac/lambda/MethodReference32.java + test/tools/javac/lambda/MethodReference32.out + test/tools/javac/lambda/MethodReference33.java + test/tools/javac/lambda/MethodReference34.java + test/tools/javac/lambda/MethodReference35.java + test/tools/javac/lambda/MethodReference36.java + test/tools/javac/lambda/MethodReference37.java + test/tools/javac/lambda/MethodReference37.out + test/tools/javac/lambda/MethodReference38.java + test/tools/javac/lambda/MethodReference38.out + test/tools/javac/lambda/MethodReference39.java + test/tools/javac/lambda/MethodReference39.out + test/tools/javac/lambda/MethodReference40.java + test/tools/javac/lambda/MethodReference40.out + test/tools/javac/lambda/MethodReference41.java + test/tools/javac/lambda/MethodReference42.java + test/tools/javac/lambda/MethodReference43.java + test/tools/javac/lambda/MethodReference44.java + test/tools/javac/lambda/MethodReference45.java + test/tools/javac/lambda/MethodReference45.out + test/tools/javac/lambda/MethodReference46.java + test/tools/javac/lambda/MethodReference47.java + test/tools/javac/lambda/MethodReference47.out + test/tools/javac/lambda/MethodReference48.java + test/tools/javac/lambda/MethodReference49.java + test/tools/javac/lambda/MethodReference50.java + test/tools/javac/lambda/MethodReference50.out + test/tools/javac/lambda/MethodReference51.java + test/tools/javac/lambda/MethodReference51.out + test/tools/javac/lambda/MethodReference52.java + test/tools/javac/lambda/MethodReference52.out + test/tools/javac/lambda/MethodReference53.java + test/tools/javac/lambda/MethodReference53.out + test/tools/javac/lambda/MethodReference54.java + test/tools/javac/lambda/MethodReference54.out ! test/tools/javac/lambda/MethodReferenceParserTest.java + test/tools/javac/lambda/MostSpecific01.java + test/tools/javac/lambda/MostSpecific01.out + test/tools/javac/lambda/MostSpecific02.java + test/tools/javac/lambda/MostSpecific02.out + test/tools/javac/lambda/MostSpecific03.java + test/tools/javac/lambda/MostSpecific03.out + test/tools/javac/lambda/MostSpecific04.java + test/tools/javac/lambda/MostSpecific05.java + test/tools/javac/lambda/MostSpecific06.java + test/tools/javac/lambda/MostSpecific06.out + test/tools/javac/lambda/MostSpecific07.java + test/tools/javac/lambda/MostSpecific07.out + test/tools/javac/lambda/NakedThis.java + test/tools/javac/lambda/SourceLevelTest.java + test/tools/javac/lambda/SourceLevelTest.out + 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/TargetType04.out + test/tools/javac/lambda/TargetType05.java + test/tools/javac/lambda/TargetType06.java + test/tools/javac/lambda/TargetType06.out + test/tools/javac/lambda/TargetType07.java + test/tools/javac/lambda/TargetType08.java + test/tools/javac/lambda/TargetType10.java + test/tools/javac/lambda/TargetType10.out + test/tools/javac/lambda/TargetType11.java + test/tools/javac/lambda/TargetType11.out + test/tools/javac/lambda/TargetType12.java + test/tools/javac/lambda/TargetType13.java + test/tools/javac/lambda/TargetType13.out + test/tools/javac/lambda/TargetType14.java + test/tools/javac/lambda/TargetType14.out + test/tools/javac/lambda/TargetType15.java + test/tools/javac/lambda/TargetType16.java + test/tools/javac/lambda/TargetType16.out + test/tools/javac/lambda/TargetType17.java + test/tools/javac/lambda/TargetType17.out + test/tools/javac/lambda/TargetType18.java + test/tools/javac/lambda/TargetType19.java + test/tools/javac/lambda/TargetType19.out + test/tools/javac/lambda/TargetType20.java + test/tools/javac/lambda/TargetType20.out + test/tools/javac/lambda/TargetType21.java + test/tools/javac/lambda/TargetType21.out + test/tools/javac/lambda/TargetType22.java + test/tools/javac/lambda/TargetType22.out + test/tools/javac/lambda/TargetType23.java + test/tools/javac/lambda/TargetType23.out + test/tools/javac/lambda/TargetType24.java + test/tools/javac/lambda/TargetType24.out + test/tools/javac/lambda/TargetType25.java + test/tools/javac/lambda/TargetType26.java + test/tools/javac/lambda/TargetType26.out + test/tools/javac/lambda/TargetType27.java + test/tools/javac/lambda/TargetType27.out + test/tools/javac/lambda/TargetType28.java + test/tools/javac/lambda/TargetType28.out + test/tools/javac/lambda/TargetType29.java + test/tools/javac/lambda/TargetType30.java + test/tools/javac/lambda/TargetType31.java + test/tools/javac/lambda/TargetType32.java + test/tools/javac/lambda/TargetType33.java + test/tools/javac/lambda/TargetType33.out + test/tools/javac/lambda/TargetType34.java + test/tools/javac/lambda/TargetType35.java + test/tools/javac/lambda/TargetType36.java + test/tools/javac/lambda/TargetType37.java + test/tools/javac/lambda/TargetType38.java + test/tools/javac/lambda/TargetType38.out + test/tools/javac/lambda/TargetType39.java + test/tools/javac/lambda/TargetType39.out + test/tools/javac/lambda/TargetType40.java + test/tools/javac/lambda/TargetType40.out + test/tools/javac/lambda/TargetType41.java + test/tools/javac/lambda/TargetType41.out + test/tools/javac/lambda/TargetType42.java + test/tools/javac/lambda/TargetType43.java + test/tools/javac/lambda/TargetType43.out + test/tools/javac/lambda/TargetType44.java + test/tools/javac/lambda/TargetType44.out + test/tools/javac/lambda/TargetType45.java + test/tools/javac/lambda/TargetType45.out + test/tools/javac/lambda/TargetType46.java + test/tools/javac/lambda/TargetType46.out + test/tools/javac/lambda/TargetType47.java + test/tools/javac/lambda/TargetType48.java + test/tools/javac/lambda/TargetType49.java + test/tools/javac/lambda/TargetType49.out + test/tools/javac/lambda/TargetType50.java + test/tools/javac/lambda/TargetType50.out ! test/tools/javac/lambda/TestInvokeDynamic.java + test/tools/javac/lambda/TestSelfRef.java + test/tools/javac/lambda/VoidCompatibility.java + test/tools/javac/lambda/VoidCompatibility.out + test/tools/javac/lambda/abort/Abort.java + test/tools/javac/lambda/badMemberRefBytecode/Main.java + test/tools/javac/lambda/badMemberRefBytecode/TestBadMemberRefBytecode.java + test/tools/javac/lambda/badMemberRefBytecode/Use.java + test/tools/javac/lambda/funcInterfaces/Helper.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg1.out + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg2.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg2.out + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg3.java + test/tools/javac/lambda/funcInterfaces/LambdaTest1_neg3.out + test/tools/javac/lambda/funcInterfaces/LambdaTest2_SAM1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_SAM2.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_SAM3.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_neg1.java + test/tools/javac/lambda/funcInterfaces/LambdaTest2_neg1.out + test/tools/javac/lambda/funcInterfaces/NonSAM1.java + test/tools/javac/lambda/funcInterfaces/NonSAM1.out + test/tools/javac/lambda/funcInterfaces/NonSAM2.java + test/tools/javac/lambda/funcInterfaces/NonSAM2.out + test/tools/javac/lambda/funcInterfaces/NonSAM3.java + test/tools/javac/lambda/funcInterfaces/NonSAM3.out + test/tools/javac/lambda/lambdaExpression/AbstractClass_neg.java + test/tools/javac/lambda/lambdaExpression/AbstractClass_neg.out + test/tools/javac/lambda/lambdaExpression/AccessNonStatic_neg.java + test/tools/javac/lambda/lambdaExpression/AccessNonStatic_neg.out + test/tools/javac/lambda/lambdaExpression/EffectivelyFinal_neg.java + test/tools/javac/lambda/lambdaExpression/EffectivelyFinal_neg.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression1.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression1.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression3.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression3.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression4.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression4.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression5.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression5.out + test/tools/javac/lambda/lambdaExpression/InvalidExpression6.java + test/tools/javac/lambda/lambdaExpression/InvalidExpression6.out + test/tools/javac/lambda/lambdaExpression/LambdaTest1.java + test/tools/javac/lambda/lambdaExpression/LambdaTest2.java + test/tools/javac/lambda/lambdaExpression/LambdaTest3.java + test/tools/javac/lambda/lambdaExpression/LambdaTest4.java + test/tools/javac/lambda/lambdaExpression/LambdaTest5.java + test/tools/javac/lambda/lambdaExpression/LambdaTest6.java + test/tools/javac/lambda/lambdaExpression/SamConversion.java + test/tools/javac/lambda/lambdaExpression/SamConversionComboTest.java + test/tools/javac/lambda/methodReference/BridgeMethod.java + test/tools/javac/lambda/methodReference/MethodRef1.java + test/tools/javac/lambda/methodReference/MethodRef2.java + test/tools/javac/lambda/methodReference/MethodRef3.java + test/tools/javac/lambda/methodReference/MethodRef4.java + test/tools/javac/lambda/methodReference/MethodRef5.java + test/tools/javac/lambda/methodReference/MethodRef6.java + test/tools/javac/lambda/methodReference/MethodRef7.java + test/tools/javac/lambda/methodReference/MethodRef_neg.java + test/tools/javac/lambda/methodReference/MethodRef_neg.out + test/tools/javac/lambda/methodReference/SamConversion.java + test/tools/javac/lambda/methodReference/SamConversionComboTest.java + test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java + test/tools/javac/lambda/speculative/A.java + test/tools/javac/lambda/speculative/DiamondFinder.java + test/tools/javac/lambda/speculative/Main.java + test/tools/javac/lambda/speculative/Main.out + test/tools/javac/lambda/typeInference/InferenceTest11.java + test/tools/javac/lambda/typeInference/InferenceTest2.java + test/tools/javac/lambda/typeInference/InferenceTest2b.java + test/tools/javac/lambda/typeInference/InferenceTest3.java + test/tools/javac/lambda/typeInference/InferenceTest4.java + test/tools/javac/lambda/typeInference/InferenceTest5.java + test/tools/javac/lambda/typeInference/InferenceTest789.java + test/tools/javac/lambda/typeInference/InferenceTest_neg1_2.java + test/tools/javac/lambda/typeInference/InferenceTest_neg1_2.out + test/tools/javac/lambda/typeInference/InferenceTest_neg5.java + test/tools/javac/lambda/typeInference/InferenceTest_neg5.out + test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java ! test/tools/javac/typeAnnotations/newlocations/BasicTest.out Changeset: c0f0c41cafa0 Author: jjg Date: 2012-11-19 11:38 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/c0f0c41cafa0 8001098: Provide a simple light-weight "plug-in" mechanism for javac Reviewed-by: mcimadamore + src/share/classes/com/sun/source/util/Plugin.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/javac/api/BasicJavacTask.java ! src/share/classes/com/sun/tools/javac/api/JavacTaskImpl.java ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/plugin/showtype/Identifiers.java + test/tools/javac/plugin/showtype/Identifiers.out + test/tools/javac/plugin/showtype/Identifiers_PI.out + test/tools/javac/plugin/showtype/ShowTypePlugin.java + test/tools/javac/plugin/showtype/Test.java Changeset: 522a1ee72340 Author: bpatel Date: 2012-11-19 16:10 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/522a1ee72340 8002304: Group methods by types in methods summary section Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlStyle.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MemberSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/activetitlebar_end.gif + src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/script.js ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/stylesheet.css ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocPaths.java + src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MethodTypes.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java + test/com/sun/javadoc/testMethodTypes/TestMethodTypes.java + test/com/sun/javadoc/testMethodTypes/pkg1/A.java + test/com/sun/javadoc/testMethodTypes/pkg1/B.java + test/com/sun/javadoc/testMethodTypes/pkg1/D.java ! test/tools/javadoc/api/basic/APITest.java Changeset: 2531de382983 Author: jjg Date: 2012-11-19 16:40 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2531de382983 8003655: Add javac.jvm.ClassFile.V52 Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java Changeset: a25c53e12bd0 Author: jjg Date: 2012-11-20 07:21 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/a25c53e12bd0 8003649: regression/langtools: tools/javac/doctree Reviewed-by: ksrini ! test/tools/javac/doctree/DocCommentTester.java Changeset: fb97eaf93d61 Author: jjg Date: 2012-11-20 07:25 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/fb97eaf93d61 8003650: java.lang.Exception: expected string not found: pkg/package-frame.html Reviewed-by: ksrini ! test/tools/javadoc/api/basic/GetTask_WriterTest.java ! test/tools/javadoc/api/basic/RunTest.java Changeset: 7538e419a588 Author: mcimadamore Date: 2012-11-20 15:43 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7538e419a588 8003663: lambda test fails on Windows Summary: fix path separator issue in test Reviewed-by: jjg ! test/tools/javac/lambda/abort/Abort.java Changeset: d898d9ee352f Author: rfield Date: 2012-11-20 09:58 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d898d9ee352f 8003639: convert lambda testng tests to jtreg and add them Reviewed-by: mcimadamore + test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/defaultMethods/fd/FDTest.java - test/tools/javac/defaultMethods/fd/shapegen/ClassCase.java - test/tools/javac/defaultMethods/fd/shapegen/Hierarchy.java - test/tools/javac/defaultMethods/fd/shapegen/HierarchyGenerator.java - test/tools/javac/defaultMethods/fd/shapegen/Rule.java - test/tools/javac/defaultMethods/fd/shapegen/RuleGroup.java - test/tools/javac/defaultMethods/fd/shapegen/TTNode.java - test/tools/javac/defaultMethods/fd/shapegen/TTParser.java - test/tools/javac/defaultMethods/fd/shapegen/TTShape.java + test/tools/javac/lambda/lambdaExecution/InInterface.java + test/tools/javac/lambda/lambdaExecution/InnerConstructor.java + test/tools/javac/lambda/lambdaExecution/LambdaTranslationTest1.java + test/tools/javac/lambda/lambdaExecution/LambdaTranslationTest2.java + test/tools/javac/lambda/lambdaExecution/TBlock.java + test/tools/javac/lambda/lambdaExecution/TMapper.java + test/tools/javac/lambda/lambdaExecution/TPredicate.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestFDCCE.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInnerDefault.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInnerInstance.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInnerVarArgsThis.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestInstance.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestNew.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestNewInner.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase1.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase2.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase4.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSuper.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSuperDefault.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestTypeConversion.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgs.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsExt.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsSuper.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsSuperDefault.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestVarArgsThis.java + test/tools/javac/lambdaShapes/TEST.properties + test/tools/javac/lambdaShapes/org/openjdk/tests/javac/FDTest.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/AttributeInjector.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFile.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFilePreprocessor.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassToInterfaceConverter.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/DirectedClassLoader.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java + test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/ClassCase.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/Hierarchy.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/HierarchyGenerator.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/Rule.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/RuleGroup.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/TTNode.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/TTParser.java + test/tools/javac/lambdaShapes/org/openjdk/tests/shapegen/TTShape.java + test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java + test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java Changeset: 09ba1bfab344 Author: lana Date: 2012-11-20 11:50 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/09ba1bfab344 Merge - src/share/classes/com/sun/tools/javac/parser/SimpleDocCommentTable.java - test/tools/javac/defaultMethods/fd/FDTest.java - test/tools/javac/defaultMethods/fd/shapegen/ClassCase.java - test/tools/javac/defaultMethods/fd/shapegen/Hierarchy.java - test/tools/javac/defaultMethods/fd/shapegen/HierarchyGenerator.java - test/tools/javac/defaultMethods/fd/shapegen/Rule.java - test/tools/javac/defaultMethods/fd/shapegen/RuleGroup.java - test/tools/javac/defaultMethods/fd/shapegen/TTNode.java - test/tools/javac/defaultMethods/fd/shapegen/TTParser.java - test/tools/javac/defaultMethods/fd/shapegen/TTShape.java - test/tools/javac/diags/examples/CantAccessArgTypeInFunctionalDesc.java - test/tools/javac/diags/examples/CantAccessReturnTypeInFunctionalDesc.java - test/tools/javac/diags/examples/CantAccessThrownTypesInFunctionalDesc.java - test/tools/javac/diags/examples/CantReturnValueForVoid.java Changeset: da48ab364ea4 Author: erikj Date: 2012-11-28 13:37 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/da48ab364ea4 8003844: build-infra: docs target isn't working properly Summary: Adding resources to bootstrap javadoc.jar. Adding missing .js resource suffix Reviewed-by: ohair, jjg, ohrstrom ! makefiles/BuildLangtools.gmk Changeset: 20230f8b0eef Author: katleman Date: 2012-11-28 14:07 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/20230f8b0eef Merge Changeset: 303b09787a69 Author: katleman Date: 2012-11-29 11:31 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/303b09787a69 Added tag jdk8-b66 for changeset 20230f8b0eef ! .hgtags Changeset: e9a13a6c9d5d Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e9a13a6c9d5d Added tag jdk8-b67 for changeset 303b09787a69 ! .hgtags Changeset: bb760d825708 Author: mcimadamore Date: 2012-12-07 18:32 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/bb760d825708 merge with jdk8-b67 ! .hgtags ! make/build.xml ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/tools/javac/code/Flags.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/AttrContext.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.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/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.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/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/Pool.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/SimpleDocCommentTable.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/Pretty.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/conditional/Conditional.java ! test/tools/javac/defaultMethods/Neg01.java ! test/tools/javac/defaultMethods/Neg02.java ! test/tools/javac/defaultMethods/Neg03.java ! test/tools/javac/defaultMethods/Neg04.java ! test/tools/javac/defaultMethods/Neg05.java ! test/tools/javac/defaultMethods/Neg06.java ! test/tools/javac/defaultMethods/Neg07.java ! test/tools/javac/defaultMethods/Neg08.java ! test/tools/javac/defaultMethods/Neg09.java ! test/tools/javac/defaultMethods/Neg10.java ! test/tools/javac/defaultMethods/Neg11.java ! test/tools/javac/defaultMethods/Neg12.java ! test/tools/javac/defaultMethods/Neg13.java ! test/tools/javac/defaultMethods/Neg14.java ! test/tools/javac/defaultMethods/Neg15.java ! test/tools/javac/defaultMethods/Neg16.java ! test/tools/javac/defaultMethods/Pos01.java ! test/tools/javac/defaultMethods/Pos02.java ! test/tools/javac/defaultMethods/Pos04.java ! test/tools/javac/defaultMethods/Pos05.java ! test/tools/javac/defaultMethods/Pos06.java ! test/tools/javac/defaultMethods/Pos07.java ! test/tools/javac/defaultMethods/Pos08.java ! test/tools/javac/defaultMethods/Pos10.java ! test/tools/javac/defaultMethods/Pos11.java ! test/tools/javac/defaultMethods/Pos12.java ! test/tools/javac/defaultMethods/Pos13.java ! test/tools/javac/defaultMethods/Pos14.java ! test/tools/javac/defaultMethods/Pos15.java ! test/tools/javac/defaultMethods/Pos16.java ! test/tools/javac/defaultMethods/TestDefaultBody.java ! test/tools/javac/defaultMethods/TestNoBridgeOnDefaults.java - test/tools/javac/defaultMethods/fd/FDTest.java - test/tools/javac/defaultMethods/fd/shapegen/ClassCase.java - test/tools/javac/defaultMethods/fd/shapegen/Hierarchy.java - test/tools/javac/defaultMethods/fd/shapegen/HierarchyGenerator.java - test/tools/javac/defaultMethods/fd/shapegen/Rule.java - test/tools/javac/defaultMethods/fd/shapegen/RuleGroup.java - test/tools/javac/defaultMethods/fd/shapegen/TTNode.java - test/tools/javac/defaultMethods/fd/shapegen/TTParser.java - test/tools/javac/defaultMethods/fd/shapegen/TTShape.java ! test/tools/javac/defaultMethods/separate/Separate.java ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/InvalidGenericLambdaTarget.java ! test/tools/javac/diags/examples/LocalVarNeedsFinal.java ! test/tools/javac/diags/examples/OverriddenDefault.java ! test/tools/javac/generics/7022054/T7022054pos1.java ! test/tools/javac/generics/7022054/T7022054pos2.java ! test/tools/javac/generics/7022054/T7022054pos2.out ! test/tools/javac/lambda/BadAccess.java ! test/tools/javac/lambda/BadAccess.out ! test/tools/javac/lambda/BadAccess02.java ! test/tools/javac/lambda/BadAccess02.out ! test/tools/javac/lambda/BadAccess03.java ! test/tools/javac/lambda/BadAccess03.out ! test/tools/javac/lambda/BadBreakContinue.java ! test/tools/javac/lambda/BadBreakContinue.out ! test/tools/javac/lambda/BadConv03.java ! test/tools/javac/lambda/BadConv03.out ! test/tools/javac/lambda/BadConv04.java ! test/tools/javac/lambda/BadConv04.out ! test/tools/javac/lambda/BadExpressionLambda.java ! test/tools/javac/lambda/BadExpressionLambda.out ! test/tools/javac/lambda/BadLambdaExpr.java ! test/tools/javac/lambda/BadLambdaPos.java ! test/tools/javac/lambda/BadLambdaPos.out ! test/tools/javac/lambda/BadMethodCall.java ! test/tools/javac/lambda/BadMethodCall.out ! test/tools/javac/lambda/BadRecovery.java ! test/tools/javac/lambda/BadRecovery.out ! test/tools/javac/lambda/BadReturn.java ! test/tools/javac/lambda/BadReturn.out ! test/tools/javac/lambda/BadStatementInLambda.java ! test/tools/javac/lambda/BadStatementInLambda.out ! test/tools/javac/lambda/BadStatementInLambda02.java ! test/tools/javac/lambda/BadStatementInLambda02.out ! test/tools/javac/lambda/BadTargetType.java ! test/tools/javac/lambda/BadTargetType.out ! test/tools/javac/lambda/Conditional01.java ! test/tools/javac/lambda/Conditional02.java ! test/tools/javac/lambda/Conditional03.java ! test/tools/javac/lambda/Conformance01.java ! test/tools/javac/lambda/Defender01.java ! test/tools/javac/lambda/DisjunctiveTypeTest.java ! test/tools/javac/lambda/EffectivelyFinal01.java ! test/tools/javac/lambda/EffectivelyFinal01.out ! test/tools/javac/lambda/EffectivelyFinalTest.java ! test/tools/javac/lambda/ErroneousArg.java ! test/tools/javac/lambda/ErroneousArg.out ! test/tools/javac/lambda/ErroneousLambdaExpr.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/LambdaCapture06.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/LambdaConv09.out ! test/tools/javac/lambda/LambdaConv10.java ! test/tools/javac/lambda/LambdaConv10.out ! test/tools/javac/lambda/LambdaConv11.java ! test/tools/javac/lambda/LambdaConv12.java ! test/tools/javac/lambda/LambdaConv13.java ! test/tools/javac/lambda/LambdaConv16.java ! test/tools/javac/lambda/LambdaConv17.java ! test/tools/javac/lambda/LambdaConv18.java ! test/tools/javac/lambda/LambdaConv18.out ! test/tools/javac/lambda/LambdaConv19.java ! test/tools/javac/lambda/LambdaConv20.java ! test/tools/javac/lambda/LambdaConv21.java ! test/tools/javac/lambda/LambdaConv21.out ! test/tools/javac/lambda/LambdaConv22.java ! test/tools/javac/lambda/LambdaConv23.java ! test/tools/javac/lambda/LambdaConv24.java ! test/tools/javac/lambda/LambdaEffectivelyFinalTest.java ! test/tools/javac/lambda/LambdaEffectivelyFinalTest.out ! 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/LambdaExpr06.java ! test/tools/javac/lambda/LambdaExpr07.java ! test/tools/javac/lambda/LambdaExpr08.java ! test/tools/javac/lambda/LambdaExpr09.java ! test/tools/javac/lambda/LambdaExpr10.java ! test/tools/javac/lambda/LambdaExpr10.out ! test/tools/javac/lambda/LambdaExpr11.java ! test/tools/javac/lambda/LambdaExpr12.java ! test/tools/javac/lambda/LambdaExpr13.java ! test/tools/javac/lambda/LambdaExpr14.java ! test/tools/javac/lambda/LambdaExpr15.java ! test/tools/javac/lambda/LambdaExpr16.java ! test/tools/javac/lambda/LambdaExpr17.java ! test/tools/javac/lambda/LambdaExpr18.java ! test/tools/javac/lambda/LambdaExpr19.java ! test/tools/javac/lambda/LambdaExpr19.out ! test/tools/javac/lambda/LambdaExpr20.java ! test/tools/javac/lambda/LambdaExprNotVoid.java ! test/tools/javac/lambda/LambdaExprNotVoid.out ! test/tools/javac/lambda/LambdaParserTest.java ! test/tools/javac/lambda/LambdaScope01.java ! test/tools/javac/lambda/LambdaScope02.java ! test/tools/javac/lambda/LambdaScope03.java ! test/tools/javac/lambda/LambdaScope04.java ! test/tools/javac/lambda/LambdaScope04.out ! 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/MethodReference04.out ! 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/MethodReference08.out ! test/tools/javac/lambda/MethodReference09.java ! test/tools/javac/lambda/MethodReference09.out ! 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/MethodReference20.out ! test/tools/javac/lambda/MethodReference21.java ! test/tools/javac/lambda/MethodReference21.out ! test/tools/javac/lambda/MethodReference22.java ! test/tools/javac/lambda/MethodReference22.out ! test/tools/javac/lambda/MethodReference23.java ! test/tools/javac/lambda/MethodReference23.out ! test/tools/javac/lambda/MethodReference24.java ! test/tools/javac/lambda/MethodReference25.java ! test/tools/javac/lambda/MethodReference26.java ! test/tools/javac/lambda/MethodReference26.out ! test/tools/javac/lambda/MethodReference27.java ! test/tools/javac/lambda/MethodReference28.java ! test/tools/javac/lambda/MethodReference28.out ! test/tools/javac/lambda/MethodReference29.java ! test/tools/javac/lambda/MethodReference30.java ! test/tools/javac/lambda/MethodReference31.java ! test/tools/javac/lambda/MethodReference32.java ! test/tools/javac/lambda/MethodReference32.out ! test/tools/javac/lambda/MethodReference33.java ! test/tools/javac/lambda/MethodReference34.java ! test/tools/javac/lambda/MethodReference35.java ! test/tools/javac/lambda/MethodReference36.java ! test/tools/javac/lambda/MethodReference37.java ! test/tools/javac/lambda/MethodReference37.out ! test/tools/javac/lambda/MethodReference38.java ! test/tools/javac/lambda/MethodReference38.out ! test/tools/javac/lambda/MethodReference39.java ! test/tools/javac/lambda/MethodReference39.out ! test/tools/javac/lambda/MethodReference40.java ! test/tools/javac/lambda/MethodReference40.out ! test/tools/javac/lambda/MethodReference41.java ! test/tools/javac/lambda/MethodReference42.java ! test/tools/javac/lambda/MethodReference43.java ! test/tools/javac/lambda/MethodReference44.java ! test/tools/javac/lambda/MethodReference45.java ! test/tools/javac/lambda/MethodReference45.out ! test/tools/javac/lambda/MethodReference46.java ! test/tools/javac/lambda/MethodReference47.java ! test/tools/javac/lambda/MethodReference47.out ! test/tools/javac/lambda/MethodReference48.java ! test/tools/javac/lambda/MethodReference49.java ! test/tools/javac/lambda/MethodReference50.java ! test/tools/javac/lambda/MethodReference50.out ! test/tools/javac/lambda/MethodReference51.java ! test/tools/javac/lambda/MethodReference51.out ! test/tools/javac/lambda/MethodReference52.java ! test/tools/javac/lambda/MethodReference52.out ! test/tools/javac/lambda/MethodReference53.java ! test/tools/javac/lambda/MethodReference53.out ! test/tools/javac/lambda/MethodReference54.java ! test/tools/javac/lambda/MethodReference54.out ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/lambda/MostSpecific01.java ! test/tools/javac/lambda/MostSpecific01.out ! test/tools/javac/lambda/MostSpecific02.java ! test/tools/javac/lambda/MostSpecific02.out ! test/tools/javac/lambda/MostSpecific03.java ! test/tools/javac/lambda/MostSpecific03.out ! test/tools/javac/lambda/MostSpecific04.java ! test/tools/javac/lambda/MostSpecific05.java ! test/tools/javac/lambda/MostSpecific06.java ! test/tools/javac/lambda/MostSpecific06.out ! test/tools/javac/lambda/MostSpecific07.java ! test/tools/javac/lambda/MostSpecific07.out ! test/tools/javac/lambda/NakedThis.java ! test/tools/javac/lambda/SourceLevelTest.java ! test/tools/javac/lambda/SourceLevelTest.out ! 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/TargetType04.out ! test/tools/javac/lambda/TargetType05.java ! test/tools/javac/lambda/TargetType06.java ! test/tools/javac/lambda/TargetType06.out ! test/tools/javac/lambda/TargetType07.java ! test/tools/javac/lambda/TargetType08.java ! test/tools/javac/lambda/TargetType10.java ! test/tools/javac/lambda/TargetType10.out ! test/tools/javac/lambda/TargetType11.java ! test/tools/javac/lambda/TargetType11.out ! test/tools/javac/lambda/TargetType12.java ! test/tools/javac/lambda/TargetType13.java ! test/tools/javac/lambda/TargetType13.out ! test/tools/javac/lambda/TargetType14.java ! test/tools/javac/lambda/TargetType14.out ! test/tools/javac/lambda/TargetType15.java ! test/tools/javac/lambda/TargetType16.java ! test/tools/javac/lambda/TargetType16.out ! test/tools/javac/lambda/TargetType17.java ! test/tools/javac/lambda/TargetType17.out ! test/tools/javac/lambda/TargetType18.java ! test/tools/javac/lambda/TargetType19.java ! test/tools/javac/lambda/TargetType20.java ! test/tools/javac/lambda/TargetType20.out ! test/tools/javac/lambda/TargetType21.java ! test/tools/javac/lambda/TargetType21.out ! test/tools/javac/lambda/TargetType22.java ! test/tools/javac/lambda/TargetType22.out ! test/tools/javac/lambda/TargetType23.java ! test/tools/javac/lambda/TargetType23.out ! test/tools/javac/lambda/TargetType24.java ! test/tools/javac/lambda/TargetType24.out ! test/tools/javac/lambda/TargetType25.java ! test/tools/javac/lambda/TargetType26.java ! test/tools/javac/lambda/TargetType26.out ! test/tools/javac/lambda/TargetType27.java ! test/tools/javac/lambda/TargetType27.out ! test/tools/javac/lambda/TargetType28.java ! test/tools/javac/lambda/TargetType28.out ! test/tools/javac/lambda/TargetType29.java ! test/tools/javac/lambda/TargetType30.java ! test/tools/javac/lambda/TargetType31.java ! test/tools/javac/lambda/TargetType32.java ! test/tools/javac/lambda/TargetType33.java ! test/tools/javac/lambda/TargetType33.out ! test/tools/javac/lambda/TargetType34.java ! test/tools/javac/lambda/TargetType35.java ! test/tools/javac/lambda/TargetType36.java ! test/tools/javac/lambda/TargetType37.java ! test/tools/javac/lambda/TargetType38.java ! test/tools/javac/lambda/TargetType38.out ! test/tools/javac/lambda/TargetType39.java ! test/tools/javac/lambda/TargetType39.out ! test/tools/javac/lambda/TargetType40.java ! test/tools/javac/lambda/TargetType40.out ! test/tools/javac/lambda/TargetType41.java ! test/tools/javac/lambda/TargetType41.out ! test/tools/javac/lambda/TargetType42.java ! test/tools/javac/lambda/TargetType43.java ! test/tools/javac/lambda/TargetType43.out ! test/tools/javac/lambda/TargetType44.java ! test/tools/javac/lambda/TargetType44.out ! test/tools/javac/lambda/TargetType45.java ! test/tools/javac/lambda/TargetType45.out ! test/tools/javac/lambda/TargetType46.java ! test/tools/javac/lambda/TargetType46.out ! test/tools/javac/lambda/TargetType47.java ! test/tools/javac/lambda/TargetType48.java ! test/tools/javac/lambda/TargetType49.java ! test/tools/javac/lambda/TargetType49.out ! test/tools/javac/lambda/TargetType50.java ! test/tools/javac/lambda/TargetType50.out ! test/tools/javac/lambda/TestSelfRef.java ! test/tools/javac/lambda/VoidCompatibility.java ! test/tools/javac/lambda/VoidCompatibility.out ! test/tools/javac/lambda/abort/Abort.java ! test/tools/javac/lambda/badMemberRefBytecode/Main.java ! test/tools/javac/lambda/badMemberRefBytecode/TestBadMemberRefBytecode.java + test/tools/javac/lambda/methodReference/MethodRef1.java + test/tools/javac/lambda/methodReference/SamConversion.java + test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java ! test/tools/javac/lambda/speculative/DiamondFinder.java ! test/tools/javac/lambda/speculative/Main.java - test/tools/javac/lambda/sqe/SAM_types/Helper.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest1.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest1_neg1.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest1_neg1.out - test/tools/javac/lambda/sqe/SAM_types/LambdaTest1_neg2.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest1_neg2.out - test/tools/javac/lambda/sqe/SAM_types/LambdaTest1_neg3.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest1_neg3.out - test/tools/javac/lambda/sqe/SAM_types/LambdaTest2_SAM1.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest2_SAM2.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest2_SAM3.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest2_neg1.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest2_neg1.out - test/tools/javac/lambda/sqe/SAM_types/NonSAM1.java - test/tools/javac/lambda/sqe/SAM_types/NonSAM1.out - test/tools/javac/lambda/sqe/SAM_types/NonSAM2.java - test/tools/javac/lambda/sqe/SAM_types/NonSAM2.out - test/tools/javac/lambda/sqe/SAM_types/NonSAM3.java - test/tools/javac/lambda/sqe/SAM_types/NonSAM3.out - test/tools/javac/lambda/sqe/lambdaExpression/AbstractClass_neg.java - test/tools/javac/lambda/sqe/lambdaExpression/AbstractClass_neg.out - test/tools/javac/lambda/sqe/lambdaExpression/AccessNonStatic_neg.java - test/tools/javac/lambda/sqe/lambdaExpression/AccessNonStatic_neg.out - test/tools/javac/lambda/sqe/lambdaExpression/EffectivelyFinal_neg.java - test/tools/javac/lambda/sqe/lambdaExpression/EffectivelyFinal_neg.out - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression1.java - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression1.out - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression3.java - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression3.out - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression4.java - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression4.out - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression5.java - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression5.out - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression6.java - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression6.out - test/tools/javac/lambda/sqe/lambdaExpression/LambdaTest1.java - test/tools/javac/lambda/sqe/lambdaExpression/LambdaTest2.java - test/tools/javac/lambda/sqe/lambdaExpression/LambdaTest3.java - test/tools/javac/lambda/sqe/lambdaExpression/LambdaTest4.java - test/tools/javac/lambda/sqe/lambdaExpression/LambdaTest5.java - test/tools/javac/lambda/sqe/lambdaExpression/LambdaTest6.java - test/tools/javac/lambda/sqe/lambdaExpression/SamConversion.java - test/tools/javac/lambda/sqe/lambdaExpression/SamConversionComboTest.java - test/tools/javac/lambda/sqe/methodReference/BridgeMethod.java - test/tools/javac/lambda/sqe/methodReference/MethodRef1.java - test/tools/javac/lambda/sqe/methodReference/MethodRef2.java - test/tools/javac/lambda/sqe/methodReference/MethodRef3.java - test/tools/javac/lambda/sqe/methodReference/MethodRef4.java - test/tools/javac/lambda/sqe/methodReference/MethodRef5.java - test/tools/javac/lambda/sqe/methodReference/MethodRef6.java - test/tools/javac/lambda/sqe/methodReference/MethodRef7.java - test/tools/javac/lambda/sqe/methodReference/MethodRef_neg.java - test/tools/javac/lambda/sqe/methodReference/MethodRef_neg.out - test/tools/javac/lambda/sqe/methodReference/SamConversion.java - test/tools/javac/lambda/sqe/methodReference/SamConversionComboTest.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest11.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest2.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest2b.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest3.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest4.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest5.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest789.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest_neg1_2.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest_neg1_2.out - test/tools/javac/lambda/sqe/typeInference/InferenceTest_neg5.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest_neg5.out - test/tools/javac/lambda/sqe/typeInference/combo/TypeInferenceComboTest.java ! test/tools/javac/nativeHeaders/NativeHeaderTest.java ! test/tools/javac/typeAnnotations/newlocations/BasicTest.out From mike.duigou at oracle.com Fri Dec 7 13:02:09 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 7 Dec 2012 13:02:09 -0800 Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: <50C088BE.1040403@oracle.com> References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> <50C035F5.4050007@oracle.com> <50C088BE.1040403@oracle.com> Message-ID: <2D5B0B63-59C9-4989-B8C7-D5A9D41FF7C0@oracle.com> On Dec 6 2012, at 03:59 , Chris Hegarty wrote: > Mike, > > Some small comments. > > 1) IntUnaryOperator.java > > Typo in: > + 30 *

This is the primitive type specialization of {@link IntUnaryOperator} for > + 31 * {@code int} and also may be used as a {@code IntUnaryOperator}. When > + 32 * used as a {@code IntUnaryOperator} the default {@code operate} implementation > + 33 * provided by this interface neither accepts null parameters nor does it return > + 34 * null results. > > IntUnaryOperator -> UnaryOperator Corrected. > > 2) Double/Int/Long Function > > "When used as a Function the default apply implementation provided > by this interface neither accepts null parameters nor does it > return null results." > > "When used as a Function", is this really necessary, or should the > behavior of the default apply method just be described? I agree that this is somewhat awkward. I will see if I can't think of something better. > Why the restriction on null parameters, it seems overly restrictive > since applyAsXXXX accepts nulls, right? Corrected. Thank you for noticing this. > 3) package description > > "null values are accepted and returned by these functional > interfaces according to the constraints of the specification in > which the functional interfaces are used. The functional interfaces > themselves do not constrain or mandate use of null values. Most > usages of the functional interfaces will define the role, if any, > of null for that context." > > Given these changes, doesn't this need to be reworked ( to indicate > that some methods specify null value behavior)? > > 4) Trivially, IntSupplier is missing a '

', before "This is the > primitive type..." > > 5) I agree with David, NPE should be defined where applicable. I am adding these though I am still somewhat resistant for reasons I will mention in next review cycle thread Mike From mike.duigou at oracle.com Fri Dec 7 13:33:46 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 07 Dec 2012 21:33:46 +0000 Subject: hg: lambda/lambda/langtools: 2 new changesets Message-ID: <20121207213352.A6AEB47FC7@hg.openjdk.java.net> Changeset: ea82ee325558 Author: erikj Date: 2012-11-28 13:37 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/ea82ee325558 8003844: build-infra: docs target isn't working properly Summary: Adding resources to bootstrap javadoc.jar. Adding missing .js resource suffix Reviewed-by: ohair, jjg, ohrstrom ! makefiles/BuildLangtools.gmk Changeset: e76a2d653fb1 Author: mduigou Date: 2012-12-07 13:33 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e76a2d653fb1 Merge - src/share/classes/com/sun/tools/javac/parser/SimpleDocCommentTable.java - test/tools/javac/defaultMethods/fd/FDTest.java - test/tools/javac/defaultMethods/fd/shapegen/ClassCase.java - test/tools/javac/defaultMethods/fd/shapegen/Hierarchy.java - test/tools/javac/defaultMethods/fd/shapegen/HierarchyGenerator.java - test/tools/javac/defaultMethods/fd/shapegen/Rule.java - test/tools/javac/defaultMethods/fd/shapegen/RuleGroup.java - test/tools/javac/defaultMethods/fd/shapegen/TTNode.java - test/tools/javac/defaultMethods/fd/shapegen/TTParser.java - test/tools/javac/defaultMethods/fd/shapegen/TTShape.java - test/tools/javac/defaultMethods/hiding/InterfaceMethodHidingTest.java - test/tools/javac/lambda/sqe/SAM_types/Helper.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest1.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest1_neg1.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest1_neg1.out - test/tools/javac/lambda/sqe/SAM_types/LambdaTest1_neg2.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest1_neg2.out - test/tools/javac/lambda/sqe/SAM_types/LambdaTest1_neg3.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest1_neg3.out - test/tools/javac/lambda/sqe/SAM_types/LambdaTest2_SAM1.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest2_SAM2.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest2_SAM3.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest2_neg1.java - test/tools/javac/lambda/sqe/SAM_types/LambdaTest2_neg1.out - test/tools/javac/lambda/sqe/SAM_types/NonSAM1.java - test/tools/javac/lambda/sqe/SAM_types/NonSAM1.out - test/tools/javac/lambda/sqe/SAM_types/NonSAM2.java - test/tools/javac/lambda/sqe/SAM_types/NonSAM2.out - test/tools/javac/lambda/sqe/SAM_types/NonSAM3.java - test/tools/javac/lambda/sqe/SAM_types/NonSAM3.out - test/tools/javac/lambda/sqe/lambdaExpression/AbstractClass_neg.java - test/tools/javac/lambda/sqe/lambdaExpression/AbstractClass_neg.out - test/tools/javac/lambda/sqe/lambdaExpression/AccessNonStatic_neg.java - test/tools/javac/lambda/sqe/lambdaExpression/AccessNonStatic_neg.out - test/tools/javac/lambda/sqe/lambdaExpression/EffectivelyFinal_neg.java - test/tools/javac/lambda/sqe/lambdaExpression/EffectivelyFinal_neg.out - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression1.java - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression1.out - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression3.java - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression3.out - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression4.java - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression4.out - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression5.java - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression5.out - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression6.java - test/tools/javac/lambda/sqe/lambdaExpression/InvalidExpression6.out - test/tools/javac/lambda/sqe/lambdaExpression/LambdaTest1.java - test/tools/javac/lambda/sqe/lambdaExpression/LambdaTest2.java - test/tools/javac/lambda/sqe/lambdaExpression/LambdaTest3.java - test/tools/javac/lambda/sqe/lambdaExpression/LambdaTest4.java - test/tools/javac/lambda/sqe/lambdaExpression/LambdaTest5.java - test/tools/javac/lambda/sqe/lambdaExpression/LambdaTest6.java - test/tools/javac/lambda/sqe/lambdaExpression/SamConversion.java - test/tools/javac/lambda/sqe/lambdaExpression/SamConversionComboTest.java - test/tools/javac/lambda/sqe/methodReference/BridgeMethod.java - test/tools/javac/lambda/sqe/methodReference/MethodRef1.java - test/tools/javac/lambda/sqe/methodReference/MethodRef2.java - test/tools/javac/lambda/sqe/methodReference/MethodRef3.java - test/tools/javac/lambda/sqe/methodReference/MethodRef4.java - test/tools/javac/lambda/sqe/methodReference/MethodRef5.java - test/tools/javac/lambda/sqe/methodReference/MethodRef6.java - test/tools/javac/lambda/sqe/methodReference/MethodRef7.java - test/tools/javac/lambda/sqe/methodReference/MethodRef_neg.java - test/tools/javac/lambda/sqe/methodReference/MethodRef_neg.out - test/tools/javac/lambda/sqe/methodReference/SamConversion.java - test/tools/javac/lambda/sqe/methodReference/SamConversionComboTest.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest11.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest2.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest2b.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest3.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest4.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest5.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest789.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest_neg1_2.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest_neg1_2.out - test/tools/javac/lambda/sqe/typeInference/InferenceTest_neg5.java - test/tools/javac/lambda/sqe/typeInference/InferenceTest_neg5.out - test/tools/javac/lambda/sqe/typeInference/combo/TypeInferenceComboTest.java From akhil.arora at oracle.com Fri Dec 7 17:42:28 2012 From: akhil.arora at oracle.com (Akhil Arora) Date: Fri, 07 Dec 2012 17:42:28 -0800 Subject: RFR: 8001647: In-place methods on Collection/List Message-ID: <50C29B04.5070508@oracle.com> As part of the Library Lambdafication, this patch adds the following default methods to Collections - Iterable.forEach(Block) Collection.removeAll(Predicate) List.sort(Comparator) List.replaceAll(UnaryOperator) It also provides more efficient implementations of these methods for ArrayList, Vector and CopyOnWriteArrayList. Please review. http://cr.openjdk.java.net/~akhil/8001647.1/webrev/ Thanks to the many people who have already contributed to this patch. From mike.duigou at oracle.com Fri Dec 7 19:25:57 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sat, 08 Dec 2012 03:25:57 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121208032619.C720947FD3@hg.openjdk.java.net> Changeset: 86868b837c72 Author: mduigou Date: 2012-12-07 13:25 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/86868b837c72 cleanups and change casts to primitives to use Primitive.primitiveValue (it's an intrinsic, don't worrry) ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/DoublePredicate.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntPredicate.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/LongPredicate.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java Changeset: 05ff4702487f Author: mduigou Date: 2012-12-07 19:25 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/05ff4702487f add tests for predicate default methods. + test/java/util/function/PredicateTest.java From peter.levart at gmail.com Sat Dec 8 04:41:20 2012 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 08 Dec 2012 13:41:20 +0100 Subject: Request for Review: CR#8001667, second attempt In-Reply-To: <32DA82DE-9FFF-4ABA-BD38-480057EADE7A@oracle.com> References: <50C041D3.9060703@oracle.com> <50C1B23E.8010003@gmail.com> <32DA82DE-9FFF-4ABA-BD38-480057EADE7A@oracle.com> Message-ID: <50C33570.9020202@gmail.com> On 12/07/2012 06:27 PM, Henry Jen wrote: > On Dec 7, 2012, at 1:09 AM, Peter Levart wrote: > >> Hi Henry, >> >> I don't know what the plans are about moving the static methods in Comparators to the Comparator interface when static interface methods are enabled, but if that is planned, there will be a clash between Comparator.reverseOrder() default method and static method with same name and signature. >> > We will be exploring that along with other classes given static default method support ready. > > Cheers, > Henry > And what about the aComparator.thenComparing(Comparator) method name? Do you think it's ok to use the same name as in aComparator.thenComparing(Function) ? A suitable alternative might be aComparator.thenUsing(Comparator). Regards, Peter From v.a.ammodytes at googlemail.com Sat Dec 8 05:11:58 2012 From: v.a.ammodytes at googlemail.com (Arne Siegel) Date: Sat, 08 Dec 2012 14:11:58 +0100 Subject: RFR: 8001647: In-place methods on Collection/List In-Reply-To: <50C29B04.5070508@oracle.com> Message-ID: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com> On 7 Dec 2012 at 17:42, Akhil Arora wrote: > As part of the Library Lambdafication, this patch adds the following > default methods to Collections - > > Iterable.forEach(Block) > Collection.removeAll(Predicate) > List.sort(Comparator) > List.replaceAll(UnaryOperator) > > It also provides more efficient implementations of these methods for > ArrayList, Vector and CopyOnWriteArrayList. Please review. > > http://cr.openjdk.java.net/~akhil/8001647.1/webrev/ > > Thanks to the many people who have already contributed to this patch. > I took a look at the ArrayList implementation. To my understanding it works fine, just got a few observations. ArrayList.java, line 1171: final boolean anyToRemove = (removeSet != null) && !removeSet.isEmpty(); As removeSet will never be null, this line can be simplified. This is a left-over from the preceding implementation (see b67). ArrayList.java, method forEach optimizes the loop by reducing the number of heap accesses: final int size = this.size; for (int i=0; modCount == expectedModCount && i < size; i++) { ... This trick might also be introduced to methods removeAll and replaceAll. In the ListIterator implementation of ArrayList, there are various appearances of the idiom: try { ... } catch (IndexOutOfBoundsException ex) { throw new ConcurrentModificationException(); } This technique might also be used in forEach, removeAll, and replaceAll (though not likely to be of any importance). Regards Arne Siegel From peter.levart at gmail.com Sat Dec 8 05:27:10 2012 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 08 Dec 2012 14:27:10 +0100 Subject: RFR: 8001647: In-place methods on Collection/List In-Reply-To: <50C29B04.5070508@oracle.com> References: <50C29B04.5070508@oracle.com> Message-ID: <50C3402E.9050608@gmail.com> On 12/08/2012 02:42 AM, Akhil Arora wrote: > As part of the Library Lambdafication, this patch adds the following > default methods to Collections - > > Iterable.forEach(Block) > Collection.removeAll(Predicate) > List.sort(Comparator) > List.replaceAll(UnaryOperator) > > It also provides more efficient implementations of these methods for > ArrayList, Vector and CopyOnWriteArrayList. Please review. Yes! There's finally a way to sort ArrayList's array in-place. Until now you either had to resort to using arrays or a sub-optimal Collections.sort(List) method. Regards, Peter From cleber at nightcoders.com.br Sun Dec 9 20:48:00 2012 From: cleber at nightcoders.com.br (Cleber Muramoto) Date: Mon, 10 Dec 2012 02:48:00 -0200 Subject: Request for binary search using functions Message-ID: Hello, every once in a while I come across the problem of having to use an incompatible key to perform a binary search, e.g.: int binarySearch(SimpleDateFormat[] array,String pattern){ ... String midVal = array[i].toPattern(); ... } (array is sorted using (l,r)->l.toPattern().compareTo(r.toPattern()) ) Of course I could use the comparator to search if the pattern where to be wrapped in a SimpleDateFormat, which is exactly what I don't want (costly object)! Couldn't we have an implementation like: public static > int binarySearch(final T[] a, final int fromIndex, final int toIndex, final K key, final Function f) { ... K midVal = f.apply(array[i]); ... } (array is sorted using (l,r)->f(l).compareTo(f(r)) ) ? Cheers! From mandrikov at gmail.com Mon Dec 10 01:07:34 2012 From: mandrikov at gmail.com (Evgeny Mandrikov) Date: Mon, 10 Dec 2012 10:07:34 +0100 Subject: JSR 335 seems outdated, not aligned with implementation Message-ID: Hi, I'm one of developers of Sonar ( http://www.sonarsource.org/ ). And looking at the fact that IntelliJ IDEA 12 already supports Java 8, I wanted to update our Java analyzer to also support changes in language, more precisely JSR-335 (lambda expressions, method and constructor references, default methods). Of course I started from specs, but quickly realized that they are different from what was implemented in OpenJDK Lambda project. For example: Part G: Default Methods - InterfaceMethodBody contains "default", whereas in reality it is part of modifiers. And maybe this is not the only one difference. Aleksey Shipilev confirmed that spec is a bit outdated and suggested to ask this question here ( https://twitter.com/shipilev/status/277898648753410049 ). So my first question - is it possible to align specification with an implementation? Otherwise too risky to do an early adoption. The second question relates to the fact that Java Language Specification ( http://docs.oracle.com/javase/specs/ ) contains two grammars - one for exposition (chapters 4, 6-10, 14 and 15) and another one, which is better suited to implementation (chapter 18). Seems that JSR-335 describes changes only in the first one. Even if they are pretty similar it would be great to know changes in the second one. Is it possible? This question relates to the fact that it took me quite some time to understand how left-recursion can be resolved between grammar rules "method reference" and "primary". I'm pretty sure that this problem was solved in reference implementation, but details of solution not exposed in the specification. Thanks in advance. -- Best regards, Evgeny Mandrikov aka Godin http://twitter.com/_godin_ From r.spilker at gmail.com Mon Dec 10 01:59:57 2012 From: r.spilker at gmail.com (Roel Spilker) Date: Mon, 10 Dec 2012 10:59:57 +0100 Subject: Feedback on the implementation of StringJoiner In-Reply-To: <50B8D792.9060601@oracle.com> References: <50B8D792.9060601@oracle.com> Message-ID: I understand. If I can help in any way, please let me know. I did sign an OCA 10 days ago, however, I don't know if it has been processed. On Fri, Nov 30, 2012 at 4:58 PM, Jim Gish wrote: > Hi Roel, > > I'll take a look. Sorry for the delay -- got pulled into other things. > > Jim > > On 11/28/2012 02:41 PM, Roel Spilker wrote: > >> Hi all, >> >> On June 25 I sent some feedback on the implementation of StringJoiner. >> Most >> of it is still relevant, none of it is addressed. Is there anything I can >> do to get the implementation to a higher level? >> >> Roel >> >> Thread containing the feedback >> http://mail.openjdk.java.net/**pipermail/lambda-dev/2012-** >> June/005078.html >> >> Link to the current implementation >> http://hg.openjdk.java.net/**lambda/lambda/jdk/file/** >> 83923cc50252/src/share/**classes/java/util/**StringJoiner.java >> >> > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.gish at oracle.com > > From chris.hegarty at oracle.com Mon Dec 10 02:33:52 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 10 Dec 2012 02:33:52 -0800 (PST) Subject: Request for Review : CR#8004015 : [final (?) pass] Add interface extends and defaults for basic functional interfaces In-Reply-To: <2D5B0B63-59C9-4989-B8C7-D5A9D41FF7C0@oracle.com> References: <0CABE1EF-B971-43A0-ABB8-3EE3D82DC029@oracle.com> <50C035F5.4050007@oracle.com> <50C088BE.1040403@oracle.com> <2D5B0B63-59C9-4989-B8C7-D5A9D41FF7C0@oracle.com> Message-ID: <50C5BA90.9010204@oracle.com> On 07/12/2012 21:02, Mike Duigou wrote: > ... >> 5) I agree with David, NPE should be defined where applicable. > > I am adding these though I am still somewhat resistant for reasons I will mention in next review cycle thread I don't want to to get bogged down in a debate over this, I'm really happy too see these changes making their way into jdk8. Maybe some text in the package description that indicates that "an exception" will be thrown in cases where the API specifies a non-null argument? I'll leave it to you to decide. All in all, this is looking good. -Chris. > > Mike > > > From Alan.Bateman at oracle.com Mon Dec 10 05:28:11 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Dec 2012 13:28:11 +0000 Subject: RFR: 8001647: In-place methods on Collection/List In-Reply-To: <50C29B04.5070508@oracle.com> References: <50C29B04.5070508@oracle.com> Message-ID: <50C5E36B.2040005@oracle.com> On 08/12/2012 01:42, Akhil Arora wrote: > As part of the Library Lambdafication, this patch adds the following > default methods to Collections - > > Iterable.forEach(Block) > Collection.removeAll(Predicate) > List.sort(Comparator) > List.replaceAll(UnaryOperator) > > It also provides more efficient implementations of these methods for > ArrayList, Vector and CopyOnWriteArrayList. Please review. > > http://cr.openjdk.java.net/~akhil/8001647.1/webrev/ > > Thanks to the many people who have already contributed to this patch. > This may be bikeshed territory but we usually don't use the "public" modifier on methods defined by interfaces as they are public anyway. It seems inconsistent to me to have it on the default methods. Perhaps this has been discussed before, in which case ignore this. BTW: The only reason I'm bringing this up is because there are lots of default methods to come and it would be nice to establish a convention and consistency from the start. One small comment on ArrayList.removeAll is that it might be more efficient to keep a count of the number of elements to remove rather than using the cardinality method (to avoid the bit scan). For the supporting classes in testlibrary then is @library needed? (I haven't fully groked how jtreg supports TestNG so perhaps @library without specifying a location or JAR file has some meaning). -Alan. From brian.goetz at oracle.com Mon Dec 10 06:50:28 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 10 Dec 2012 09:50:28 -0500 Subject: JSR 335 seems outdated, not aligned with implementation In-Reply-To: References: Message-ID: <50C5F6B4.4010006@oracle.com> I think you have a mistaken assumption, that there is some part of JSR-335 that is "done" and that the other parts are "not caught up." The actual situation is that everything is in active development -- the design, the specs, the compiler implementation, the libraries, and the third-party IDEs like IntelliJ that are valiently keeping up with a moving target. It sounds like you are not ready to be an early adopter -- which is fine. Stay tuned here to track how the spec and implementation are evolving, and for a hint as to when they start settling. But if you want to start blazing a trail now, you'll find support here. Thanks for checking in! On 12/10/2012 4:07 AM, Evgeny Mandrikov wrote: > Hi, > > I'm one of developers of Sonar ( http://www.sonarsource.org/ ). And looking > at the fact that IntelliJ IDEA 12 already supports Java 8, I wanted to > update our Java analyzer to also support changes in language, more > precisely JSR-335 (lambda expressions, method and constructor references, > default methods). > > Of course I started from specs, but quickly realized that they are > different from what was implemented in OpenJDK Lambda project. For example: > Part G: Default Methods - InterfaceMethodBody contains "default", whereas > in reality it is part of modifiers. And maybe this is not the only one > difference. Aleksey Shipilev confirmed that spec is a bit outdated and > suggested to ask this question here ( > https://twitter.com/shipilev/status/277898648753410049 ). So my first > question - is it possible to align specification with an > implementation? Otherwise too risky to do an early adoption. > > The second question relates to the fact that Java Language Specification ( > http://docs.oracle.com/javase/specs/ ) contains two grammars - one for > exposition (chapters 4, 6-10, 14 and 15) and another one, which is better > suited to implementation (chapter 18). Seems that JSR-335 describes changes > only in the first one. Even if they are pretty similar it would be great to > know changes in the second one. Is it possible? This question relates to > the fact that it took me quite some time to understand how left-recursion > can be resolved between grammar rules "method reference" and "primary". I'm > pretty sure that this problem was solved in reference implementation, but > details of solution not exposed in the specification. > > Thanks in advance. > > From paul.sandoz at oracle.com Mon Dec 10 07:11:47 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 10 Dec 2012 15:11:47 +0000 Subject: hg: lambda/lambda/jdk: Dramtic simplification of AbstractPipeline: when chaining a stateful Message-ID: <20121210151215.530AB47016@hg.openjdk.java.net> Changeset: de7c1b2d7645 Author: psandoz Date: 2012-12-10 16:11 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/de7c1b2d7645 Dramtic simplification of AbstractPipeline: when chaining a stateful op on a parallel stream a new stream will be created with a supplier of a spliterator that defers evaluation to a node from which the spliterator is obtained. This also enables arbitrary sequential/parallel declarations. (Optimization for collection if the source spliterator supplier is backed by a Node will be added back in a future commit.) Contributed-by: Brian Goetz Contributed-by: Paul Sandoz ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/ParallelPipelineHelper.java ! src/share/classes/java/util/stream/PipelineHelper.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/StreamShape.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/op/AbstractTask.java ! src/share/classes/java/util/stream/op/CumulateOp.java ! src/share/classes/java/util/stream/op/GroupByOp.java ! src/share/classes/java/util/stream/op/IntermediateOp.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/op/ReduceByOp.java ! src/share/classes/java/util/stream/op/SortedOp.java ! src/share/classes/java/util/stream/op/TreeUtils.java ! src/share/classes/java/util/stream/op/UniqOp.java ! src/share/classes/java/util/stream/primitive/IntCumulateOp.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java ! src/share/classes/java/util/stream/primitive/IntTreeUtils.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SequentialOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SortedOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UniqOpTest.java From scolebourne at joda.org Mon Dec 10 07:52:52 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 10 Dec 2012 15:52:52 +0000 Subject: RFR: 8001647: In-place methods on Collection/List In-Reply-To: <50C5E36B.2040005@oracle.com> References: <50C29B04.5070508@oracle.com> <50C5E36B.2040005@oracle.com> Message-ID: On 10 December 2012 13:28, Alan Bateman wrote: > On 08/12/2012 01:42, Akhil Arora wrote: >> As part of the Library Lambdafication, this patch adds the following >> default methods to Collections - >> >> Iterable.forEach(Block) >> Collection.removeAll(Predicate) >> List.sort(Comparator) >> List.replaceAll(UnaryOperator) >> >> It also provides more efficient implementations of these methods for >> ArrayList, Vector and CopyOnWriteArrayList. Please review. >> >> http://cr.openjdk.java.net/~akhil/8001647.1/webrev/ >> >> Thanks to the many people who have already contributed to this patch. >> > This may be bikeshed territory but we usually don't use the "public" > modifier on methods defined by interfaces as they are public anyway. It > seems inconsistent to me to have it on the default methods. Perhaps this has > been discussed before, in which case ignore this. BTW: The only reason I'm > bringing this up is because there are lots of default methods to come and it > would be nice to establish a convention and consistency from the start. I agree that consistency would be good. FWIW, I think there is a case to use public everywhere now on interfaces, and effectively discourage use of the "default". This would position the interfaces in a better place were a new "package" modifier to be added in JDK9 (such as to allow package scoped methods on interfaces, now they have trait-like behaviour). Stephen From maurizio.cimadamore at oracle.com Mon Dec 10 07:54:01 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 10 Dec 2012 15:54:01 +0000 Subject: hg: lambda/lambda/langtools: Fix: Add extra checks when lambda/method ref is converted to intersection type In-Reply-To: References: <20121128103215.E2D0947B6F@hg.openjdk.java.net> Message-ID: <50C60599.3030602@oracle.com> On 28/11/12 18:41, Boaz Nahum wrote: > Can you explain why? > If I1 and I2 have same SAM why (I1 & I2) is not valid? > Can also explain why the order does matter? I forgot to reply on this one - the idea is that type-erasuer already introduce order-dependency on intersection types (i.e. the erasure of A & B & C is A). So it makes sense to give special properties to the first type of an intersection in the context of a SAM conversion. Maurizio > Thx > (sorry foy English ) > Boaz > On Nov 28, 2012 12:34 PM, wrote: > >> Changeset: 7fa8e7c02baa >> Author: mcimadamore >> Date: 2012-11-28 10:31 +0000 >> URL: >> http://hg.openjdk.java.net/lambda/lambda/langtools/rev/7fa8e7c02baa >> >> Fix: Add extra checks when lambda/method ref is converted to intersection >> type >> >> A lambda/methdod reference can be converted to an intersection type >> provided that: >> >> *) All types in the intersection are interface types >> *) The first type of the intersection is a functional interface >> *) The additional bounds of the intersection are marker interfaces >> >> ! 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/resources/compiler.properties >> ! test/tools/javac/diags/examples.not-yet.txt >> + test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java >> >> >> From aleksey.shipilev at oracle.com Mon Dec 10 08:02:41 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 10 Dec 2012 20:02:41 +0400 Subject: Par vs. Seq decomposition experiment update Message-ID: <50C607A1.2060608@oracle.com> Hi, Dust had settled over FJP, and other library changes, so here is the update on my par-vs-seq experiments. We are using the same decomposition benchmark on 2x8x2 Xeon E5-2680 (SandyBridge) running Solaris 11, and 20121203 lambda nightly with -d64 -XX:-TieredCompilation -XX:+UseParallelOldGC -XX:+UseNUMA -XX:-UseBiasedLocking -XX:+UseCondCardMark. tl;dr version of the experiment: hand-crafted stream source for longs in (0; N], simple filter (with variable cost Q) to empty sink, called by C clients, stream operations services by (fj)pool of size P. We concentrate on C=1, P=32 plane in this experiment. Clients are requesting the pipeline computation every once in a while, we let 10ms thinktime between requests for everything to settle down (this is a harsh mode for FJP to run in, but realistic enough for our use cases). Having thinktimes greatly reduces the number of tasks, and so we are able to do proper time sampling, which in turn lets us to compute percentiles on execution times. This filters out GCs, as well as provide more insights into the variance. The results are here: http://shipilev.net/pub/jdk/lambda/20121205-breakeven/ There are lots of data, but not too complex. BIRD'S EYE VIEW: breakeven.pdf [1] showcases the ratios between seq and par times: * with large enough N and Q we are enjoying very nice speedups, up to scaling nearly perfectly on the target machine, on almost all percentile values. The only exception is max time, which is problematic for parallel versions (due to longer GCs incurring more stalls with more threads?) * as usual, break-even front seems to lie through N*Q isoline, somewhere around N*Q = 10^5 for min time, and N*Q = 5*10^4 for p90. times.pdf [2] showcases the raw execution times: * it is probably more convenient to look at logarithmic scales * seq seems to react nicely to both N and Q, except for max time again, which is more affected by N (my hypothesis is that we have much better chance to hit GC with larger N during the measurement window) * par execution times are consistently worse, and the only reason why par is winning in [1] is parallelism spreads.pdf [3] showcases the execution time spreads: * seq experiences very low variance with large N*Q * seq experiences mediocre variance with low N*Q (I'd speculate, playing against power states here) * the weird and reproducible behavior is that seq has the red area right on break-even front, where variance is really high! * par experiences more or less consistent variance across N*Q FORK/JOIN TRACES: As usual, we do fjp-trace [4] on some break-even point to understand how FJP performs there. The sample decomposition tree for parallel operation at N=100, Q=1000 is here [5]: * submitter/common pool changes are settled in, so submitter is doing lots of work * first thread wakes up in the pool 100us after the submission * full-blown parallelism is there 200us after the submission * we run with full parallel for another ~200us * the final handoff burns another 40us * there are lots of completion actions, and their summary impact is more or less visible, if you count the total times between the events: EXEC -> EXECUTED: 7021ms COMPLETING -> COMPLETED: 1603ms For the reference, this is how N=1000, Q=100000 (very saturated FJP) looks like [6]. What's interesting is that completions are taking much less time there: EXEC -> EXECUTED: 117537ms COMPLETING -> COMPLETED: 123ms Maybe this is something worth for me to look at. I think Doug had some thoughts on the completion mechanics we have right now. Thanks, Aleksey. [1] http://shipilev.net/pub/jdk/lambda/20121205-breakeven/breakeven.pdf [2] http://shipilev.net/pub/jdk/lambda/20121205-breakeven/times.pdf [3] http://shipilev.net/pub/jdk/lambda/20121205-breakeven/spreads.pdf [4] https://github.com/shipilev/fjp-trace [5] http://shipilev.net/pub/jdk/lambda/20121205-breakeven/fjp-breakeven/forkjoin.trace-subtrees.png [6] http://shipilev.net/pub/jdk/lambda/20121205-breakeven/fjp-full/forkjoin.trace-subtrees.png From brian.goetz at oracle.com Mon Dec 10 08:21:00 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 10 Dec 2012 11:21:00 -0500 Subject: Par vs. Seq decomposition experiment update In-Reply-To: <50C607A1.2060608@oracle.com> References: <50C607A1.2060608@oracle.com> Message-ID: <50C60BEC.5010603@oracle.com> Has the N*Q isoline moved closer to the origin compared to previous experiments? Separately, I have a good understanding of what N=10^3 means. But how much "real computation" does Q=10^2 mean? On 12/10/2012 11:02 AM, Aleksey Shipilev wrote: > Hi, > > Dust had settled over FJP, and other library changes, so here is the > update on my par-vs-seq experiments. We are using the same decomposition > benchmark on 2x8x2 Xeon E5-2680 > (SandyBridge) running Solaris 11, and 20121203 lambda nightly with -d64 > -XX:-TieredCompilation -XX:+UseParallelOldGC -XX:+UseNUMA > -XX:-UseBiasedLocking -XX:+UseCondCardMark. > > tl;dr version of the experiment: hand-crafted stream source for longs in > (0; N], simple filter (with variable cost Q) to empty sink, called by C > clients, stream operations services by (fj)pool of size P. > > We concentrate on C=1, P=32 plane in this experiment. > > Clients are requesting the pipeline computation every once in a while, > we let 10ms thinktime between requests for everything to settle down > (this is a harsh mode for FJP to run in, but realistic enough for our > use cases). Having thinktimes greatly reduces the number of tasks, and > so we are able to do proper time sampling, which in turn lets us to > compute percentiles on execution times. This filters out GCs, as well as > provide more insights into the variance. > > The results are here: > http://shipilev.net/pub/jdk/lambda/20121205-breakeven/ > > There are lots of data, but not too complex. > > BIRD'S EYE VIEW: > > breakeven.pdf [1] showcases the ratios between seq and par times: > * with large enough N and Q we are enjoying very nice speedups, up to > scaling nearly perfectly on the target machine, on almost all percentile > values. The only exception is max time, which is problematic for > parallel versions (due to longer GCs incurring more stalls with more > threads?) > * as usual, break-even front seems to lie through N*Q isoline, > somewhere around N*Q = 10^5 for min time, and N*Q = 5*10^4 for p90. > > times.pdf [2] showcases the raw execution times: > * it is probably more convenient to look at logarithmic scales > * seq seems to react nicely to both N and Q, except for max time > again, which is more affected by N (my hypothesis is that we have much > better chance to hit GC with larger N during the measurement window) > * par execution times are consistently worse, and the only reason why > par is winning in [1] is parallelism > > spreads.pdf [3] showcases the execution time spreads: > * seq experiences very low variance with large N*Q > * seq experiences mediocre variance with low N*Q (I'd speculate, > playing against power states here) > * the weird and reproducible behavior is that seq has the red area > right on break-even front, where variance is really high! > * par experiences more or less consistent variance across N*Q > > > FORK/JOIN TRACES: > > As usual, we do fjp-trace [4] on some break-even point to understand how > FJP performs there. The sample decomposition tree for parallel operation > at N=100, Q=1000 is here [5]: > * submitter/common pool changes are settled in, so submitter is doing > lots of work > * first thread wakes up in the pool 100us after the submission > * full-blown parallelism is there 200us after the submission > * we run with full parallel for another ~200us > * the final handoff burns another 40us > * there are lots of completion actions, and their summary impact is > more or less visible, if you count the total times between the events: > EXEC -> EXECUTED: 7021ms > COMPLETING -> COMPLETED: 1603ms > > > For the reference, this is how N=1000, Q=100000 (very saturated FJP) > looks like [6]. What's interesting is that completions are taking much > less time there: > EXEC -> EXECUTED: 117537ms > COMPLETING -> COMPLETED: 123ms > > Maybe this is something worth for me to look at. I think Doug had some > thoughts on the completion mechanics we have right now. > > Thanks, > Aleksey. > > [1] http://shipilev.net/pub/jdk/lambda/20121205-breakeven/breakeven.pdf > [2] http://shipilev.net/pub/jdk/lambda/20121205-breakeven/times.pdf > [3] http://shipilev.net/pub/jdk/lambda/20121205-breakeven/spreads.pdf > [4] https://github.com/shipilev/fjp-trace > [5] > http://shipilev.net/pub/jdk/lambda/20121205-breakeven/fjp-breakeven/forkjoin.trace-subtrees.png > [6] > http://shipilev.net/pub/jdk/lambda/20121205-breakeven/fjp-full/forkjoin.trace-subtrees.png > From henry.jen at oracle.com Mon Dec 10 08:26:13 2012 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 10 Dec 2012 08:26:13 -0800 Subject: Feedback on the implementation of StringJoiner In-Reply-To: References: <50B8D792.9060601@oracle.com> Message-ID: Hi Roel, I am doing some changes to adapt your feedbacks and trying to have minimum but enough APIs, latest proposed can be found at http://cr.openjdk.java.net/~henryjen/lambda/StringJoiner.1/webrev/ - remove add(CharSequence...) and add(char[]) from StringJoiner - make StringJoiner(CharSequence) public and return StringJoiner. This should be enough to cover cases where stream not available and we just want to concat a few items. Also this is the only form we need for String.join() - Remove [AbstractStringBuilder/StringBuilder/StringBuffer].join(), in favor of .append(String.join(..)). Essentially the same and API is more comprehensive. - Disallow null container(Iterable, Stream, varargs, etc), tolerate container to have null content. Feel free to send your feedbacks. Thanks for the review. Cheers, Henry On Dec 10, 2012, at 1:59 AM, Roel Spilker wrote: > I understand. If I can help in any way, please let me know. I did sign an > OCA 10 days ago, however, I don't know if it has been processed. > > > On Fri, Nov 30, 2012 at 4:58 PM, Jim Gish wrote: > >> Hi Roel, >> >> I'll take a look. Sorry for the delay -- got pulled into other things. >> >> Jim >> >> On 11/28/2012 02:41 PM, Roel Spilker wrote: >> >>> Hi all, >>> >>> On June 25 I sent some feedback on the implementation of StringJoiner. >>> Most >>> of it is still relevant, none of it is addressed. Is there anything I can >>> do to get the implementation to a higher level? >>> >>> Roel >>> >>> Thread containing the feedback >>> http://mail.openjdk.java.net/**pipermail/lambda-dev/2012-** >>> June/005078.html >>> >>> Link to the current implementation >>> http://hg.openjdk.java.net/**lambda/lambda/jdk/file/** >>> 83923cc50252/src/share/**classes/java/util/**StringJoiner.java >>> >>> >> -- >> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >> Oracle Java Platform Group | Core Libraries Team >> 35 Network Drive >> Burlington, MA 01803 >> jim.gish at oracle.com >> >> > From venkats at agiledeveloper.com Mon Dec 10 09:04:50 2012 From: venkats at agiledeveloper.com (Venkat Subramaniam) Date: Mon, 10 Dec 2012 10:04:50 -0700 Subject: map and reduce functions on list In-Reply-To: References: <50B8D792.9060601@oracle.com> Message-ID: Greetings, Currently playing with b67 build and having a great time with it. To use the map and reduce functions on a list, I'm calling the stream() method first on a list. It would be convenient to have these methods directly on an Iterable (like it was in a version a few months ago). Are there plans to bring these methods back on Iterable or is doing the conversion to Stream the path forward. My sincere apologies if this was discussed earlier and I totally missed it (a quick scan on the list did not help me find the discussion). Much appreciate the response. Thank you Venkat From paul.sandoz at oracle.com Mon Dec 10 09:44:25 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 10 Dec 2012 18:44:25 +0100 Subject: map and reduce functions on list In-Reply-To: References: <50B8D792.9060601@oracle.com> Message-ID: On Dec 10, 2012, at 6:04 PM, Venkat Subramaniam wrote: > Greetings, > > Currently playing with b67 build and having a great time with it. > > To use the map and reduce functions on a list, I'm calling the stream() method first > on a list. It would be convenient to have these methods directly on an Iterable (like > it was in a version a few months ago). Are there plans to bring these methods > back on Iterable No plans. > or is doing the conversion to Stream the path forward. > Yes. Among other things it is far less intrusive approach to evolving the collections API and allows for integration into classes such as Random and BufferedReader. Paul. > My sincere apologies if this was discussed earlier and I totally missed it (a quick scan on > the list did not help me find the discussion). Much appreciate the response. > > Thank you > > Venkat > From brian.goetz at oracle.com Mon Dec 10 09:45:48 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 10 Dec 2012 12:45:48 -0500 Subject: map and reduce functions on list In-Reply-To: References: <50B8D792.9060601@oracle.com> Message-ID: <50C61FCC.4080204@oracle.com> Yes, this is a common question. The short answer is no. The reason is: Iterable has strong associations with "something that can be iterated multiple times" (even though the spec doesn't come right out and say that.) Streams are more like IteratOR than IteraBLE. But some stream sources might be fed by IO, and would not be Iterable. Having the stream methods on Iterable led to multiple forms of confusion. (We got a lot of confused queries along the line of "how do I know whether the collection is in eager or lazy mode?" Obviously this doesn't make sense, but if this is what stuffing the methods into Iterable makes people think, that's a bad sign.) Further, if the methods were on Iterable, then Collection would have a mix of eager and lazy methods with similar names, and the net result would be very confusing. For example, filter(Predicate) is lazy and creates a new Stream, but removeAll(Predicate) mutates the collection in-place. A user hitting ctrl-space would then have to reason about which are the "mutative old" method and which are the "functional new" ones. Not what we were trying to do. The syntactic overhead of the stream() call is regrettable -- it took us a long time to get over it too -- but once you get past the distaste, the resulting model is dramatically cleaner. On 12/10/2012 12:04 PM, Venkat Subramaniam wrote: > Greetings, > > Currently playing with b67 build and having a great time with it. > > To use the map and reduce functions on a list, I'm calling the stream() method first > on a list. It would be convenient to have these methods directly on an Iterable (like > it was in a version a few months ago). Are there plans to bring these methods > back on Iterable or is doing the conversion to Stream the path forward. > > My sincere apologies if this was discussed earlier and I totally missed it (a quick scan on > the list did not help me find the discussion). Much appreciate the response. > > Thank you > > Venkat > From venkats at agiledeveloper.com Mon Dec 10 09:52:57 2012 From: venkats at agiledeveloper.com (Venkat Subramaniam) Date: Mon, 10 Dec 2012 10:52:57 -0700 Subject: map and reduce functions on list In-Reply-To: <50C61FCC.4080204@oracle.com> References: <50B8D792.9060601@oracle.com> <50C61FCC.4080204@oracle.com> Message-ID: <2F5EF62C-412F-4E9F-A5F5-7B619393DB9F@agiledeveloper.com> Paul and Brian, Thanks for the response and the explanation. Other than a minor loss of conciseness, this seems to be working out fairly well. I don't feel any burden going through the stream. It certainly helped to learn the "why" behind it - thanks. Regards, Venkat On Dec 10, 2012, at 10:45 AM, Brian Goetz wrote: > Yes, this is a common question. The short answer is no. > > The reason is: Iterable has strong associations with "something that can be iterated multiple times" (even though the spec doesn't come right out and say that.) Streams are more like IteratOR than IteraBLE. But some stream sources might be fed by IO, and would not be Iterable. Having the stream methods on Iterable led to multiple forms of confusion. (We got a lot of confused queries along the line of "how do I know whether the collection is in eager or lazy mode?" Obviously this doesn't make sense, but if this is what stuffing the methods into Iterable makes people think, that's a bad sign.) > > Further, if the methods were on Iterable, then Collection would have a mix of eager and lazy methods with similar names, and the net result would be very confusing. For example, filter(Predicate) is lazy and creates a new Stream, but removeAll(Predicate) mutates the collection in-place. A user hitting ctrl-space would then have to reason about which are the "mutative old" method and which are the "functional new" ones. Not what we were trying to do. > > The syntactic overhead of the stream() call is regrettable -- it took us a long time to get over it too -- but once you get past the distaste, the resulting model is dramatically cleaner. > > On 12/10/2012 12:04 PM, Venkat Subramaniam wrote: >> Greetings, >> >> Currently playing with b67 build and having a great time with it. >> >> To use the map and reduce functions on a list, I'm calling the stream() method first >> on a list. It would be convenient to have these methods directly on an Iterable (like >> it was in a version a few months ago). Are there plans to bring these methods >> back on Iterable or is doing the conversion to Stream the path forward. >> >> My sincere apologies if this was discussed earlier and I totally missed it (a quick scan on >> the list did not help me find the discussion). Much appreciate the response. >> >> Thank you >> >> Venkat >> From mandrikov at gmail.com Mon Dec 10 12:56:45 2012 From: mandrikov at gmail.com (Evgeny Mandrikov) Date: Mon, 10 Dec 2012 21:56:45 +0100 Subject: JSR 335 seems outdated, not aligned with implementation In-Reply-To: <50C5F6B4.4010006@oracle.com> References: <50C5F6B4.4010006@oracle.com> Message-ID: Hi Brian, First of all - thanks for your quick answer. Maybe my sentences were too strict. So I'll try to put this a bit differently: I'm ready to be an early adopter and spend time by following changes in specs. My question was more about how to be notified about such changes without digging too much into codebase of OpenJDK. E.g. when planned to update specs to reflect recent changes? On Mon, Dec 10, 2012 at 3:50 PM, Brian Goetz wrote: > I think you have a mistaken assumption, that there is some part of JSR-335 > that is "done" and that the other parts are "not caught up." The actual > situation is that everything is in active development -- the design, the > specs, the compiler implementation, the libraries, and the third-party IDEs > like IntelliJ that are valiently keeping up with a moving target. > > It sounds like you are not ready to be an early adopter -- which is fine. > Stay tuned here to track how the spec and implementation are evolving, and > for a hint as to when they start settling. But if you want to start > blazing a trail now, you'll find support here. > > Thanks for checking in! > > > On 12/10/2012 4:07 AM, Evgeny Mandrikov wrote: > >> Hi, >> >> I'm one of developers of Sonar ( http://www.sonarsource.org/ ). And >> looking >> at the fact that IntelliJ IDEA 12 already supports Java 8, I wanted to >> update our Java analyzer to also support changes in language, more >> precisely JSR-335 (lambda expressions, method and constructor references, >> default methods). >> >> Of course I started from specs, but quickly realized that they are >> different from what was implemented in OpenJDK Lambda project. For >> example: >> Part G: Default Methods - InterfaceMethodBody contains "default", whereas >> in reality it is part of modifiers. And maybe this is not the only one >> difference. Aleksey Shipilev confirmed that spec is a bit outdated and >> suggested to ask this question here ( >> https://twitter.com/shipilev/**status/277898648753410049). So my first >> question - is it possible to align specification with an >> implementation? Otherwise too risky to do an early adoption. >> >> The second question relates to the fact that Java Language Specification ( >> http://docs.oracle.com/javase/**specs/) contains two grammars - one for >> exposition (chapters 4, 6-10, 14 and 15) and another one, which is better >> suited to implementation (chapter 18). Seems that JSR-335 describes >> changes >> only in the first one. Even if they are pretty similar it would be great >> to >> know changes in the second one. Is it possible? This question relates to >> the fact that it took me quite some time to understand how left-recursion >> can be resolved between grammar rules "method reference" and "primary". >> I'm >> pretty sure that this problem was solved in reference implementation, but >> details of solution not exposed in the specification. >> >> Thanks in advance. >> >> >> -- Best regards, Evgeny Mandrikov aka Godin http://twitter.com/_godin_ From pbenedict at apache.org Mon Dec 10 13:09:52 2012 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 10 Dec 2012 15:09:52 -0600 Subject: Collection stream() and parallel() Message-ID: I was surprised to see both these methods return Streams with such wildly different method names. After seeing stream(), I was not expecting another method to return streams -- it seemed like the former was the "de facto" way of getting one. Would you consider perhaps renaming them? Something akin to serialStream() and parallelStream()? Or streamSerially() and streamParallely()? Paul From brian.goetz at oracle.com Mon Dec 10 13:41:14 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 10 Dec 2012 16:41:14 -0500 Subject: Collection stream() and parallel() In-Reply-To: References: Message-ID: <50C656FA.4060006@oracle.com> This is under discussion in the EG now. On 12/10/2012 4:09 PM, Paul Benedict wrote: > I was surprised to see both these methods return Streams with such > wildly different method names. After seeing stream(), I was not > expecting another method to return streams -- it seemed like the > former was the "de facto" way of getting one. > > Would you consider perhaps renaming them? Something akin to > serialStream() and parallelStream()? Or streamSerially() and > streamParallely()? > > Paul > From brian.goetz at oracle.com Mon Dec 10 13:46:10 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 10 Dec 2012 16:46:10 -0500 Subject: JSR 335 seems outdated, not aligned with implementation In-Reply-To: References: <50C5F6B4.4010006@oracle.com> Message-ID: <50C65822.5040608@oracle.com> > Maybe my sentences were too strict. So I'll try to put this a bit > differently: I'm ready to be an early adopter and spend time by > following changes in specs. My question was more about how to be > notified about such changes without digging too much into codebase of > OpenJDK. E.g. when planned to update specs to reflect recent changes? Then -- welcome! We're happy to have tools like Sonar as early adopters! So, here's a rough description of the current status. - The EG has agreed on most of the major points for the language, especially as to how it affects syntax and parsing. There are still fine points being resolved on the interaction of type inference and method overload selection, but this probably doesn't affect Sonar. This is a good time to start thinking about tool support for new language features. - The recent 0.6.0 specification mostly captures the language and VM decisions made so far. - The implementation in the lambda repository is mostly, but not entirely, caught up with the 0.6.0 specification. - The periodic binary drops on the Project Lambda OpenJDK page are often a few weeks behind the current lambda repository tip. - The implementation in the JDK8 repository and drops lags the lambda repository further, but what is there is expected to be stable. From akhil.arora at oracle.com Mon Dec 10 13:48:25 2012 From: akhil.arora at oracle.com (Akhil Arora) Date: Mon, 10 Dec 2012 13:48:25 -0800 Subject: RFR: 8001647: In-place methods on Collection/List In-Reply-To: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com> References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com> Message-ID: <50C658A9.30607@oracle.com> Updated with yours and Alan's comments - http://cr.openjdk.java.net/~akhil/8001647.2/webrev/ - removed null check for removeSet - cache this.size in removeAll, replaceAll (for ArrayList, Vector and CopyOnWriteArrayList) - calculate removeCount instead of BitCount.cardinality() - removed unnecessary @library from test support classes Catching IndexOOB and throwing CME in forEach/removeAll/replaceAll seems unecessary... did you have a use-case in mind where an IndexOOB can occur with these methods? Thanks On 12/08/2012 05:11 AM, Arne Siegel wrote: > ArrayList.java, line 1171: > final boolean anyToRemove = (removeSet != null) && !removeSet.isEmpty(); > As removeSet will never be null, this line can be simplified. This is a left-over from the > preceding implementation (see b67). > > ArrayList.java, method forEach optimizes the loop by reducing the number of heap accesses: > final int size = this.size; > for (int i=0; modCount == expectedModCount && i < size; i++) { > ... > This trick might also be introduced to methods removeAll and replaceAll. > > In the ListIterator implementation of ArrayList, there are various appearances of the idiom: > try { > ... > } catch (IndexOutOfBoundsException ex) { > throw new ConcurrentModificationException(); > } > This technique might also be used in forEach, removeAll, and replaceAll (though not likely to > be of any importance). > > Regards > Arne Siegel > From pbenedict at apache.org Mon Dec 10 13:49:26 2012 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 10 Dec 2012 15:49:26 -0600 Subject: Collection stream() and parallel() In-Reply-To: <50C656FA.4060006@oracle.com> References: <50C656FA.4060006@oracle.com> Message-ID: Brian, can I post my suggestion here or must I subscribe to lambda-libs-spec-observers at openjdk.java.net? PS: The problem with ALL observers list is that they are totally worthless, in my opinion, because they all warn "EG members are under no obligation to follow the traffic on this list". If I post there, it sounds like no one will read them to reply -- so I feel I am writing into a black hole. Paul On Mon, Dec 10, 2012 at 3:41 PM, Brian Goetz wrote: > This is under discussion in the EG now. > > > On 12/10/2012 4:09 PM, Paul Benedict wrote: >> >> I was surprised to see both these methods return Streams with such >> wildly different method names. After seeing stream(), I was not >> expecting another method to return streams -- it seemed like the >> former was the "de facto" way of getting one. >> >> Would you consider perhaps renaming them? Something akin to >> serialStream() and parallelStream()? Or streamSerially() and >> streamParallely()? >> >> Paul >> > From mike.duigou at oracle.com Mon Dec 10 13:59:02 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 10 Dec 2012 13:59:02 -0800 Subject: RFR: 8001647: In-place methods on Collection/List In-Reply-To: <50C5E36B.2040005@oracle.com> References: <50C29B04.5070508@oracle.com> <50C5E36B.2040005@oracle.com> Message-ID: <65E39782-6530-47CB-A1FC-741A5B9ED4E2@oracle.com> On Dec 10 2012, at 05:28 , Alan Bateman wrote: > On 08/12/2012 01:42, Akhil Arora wrote: >> As part of the Library Lambdafication, this patch adds the following >> default methods to Collections - >> > This may be bikeshed territory but we usually don't use the "public" modifier on methods defined by interfaces as they are public anyway. Adding "public" was at my suggestion. > It seems inconsistent to me to have it on the default methods. Perhaps this has been discussed before, in which case ignore this. BTW: The only reason I'm bringing this up is because there are lots of default methods to come and it would be nice to establish a convention and consistency from the start. Agreed that we should be consistent. The suggestion to add "public" isn't related specifically to the default but anticipates, perhaps prematurely, future addition of "package" "module" and "protected" modifiers. When those modifiers are added it will make sense to be explicit about the access of a method. Additionally, some have complained about the difference in default access between interfaces and classes (public vs package) and prefer to explicit so that the intent is obvious and that method signature text in interfaces and classes look the same. So, worthwhile or not? Mike From brian.goetz at oracle.com Mon Dec 10 14:09:03 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 10 Dec 2012 17:09:03 -0500 Subject: Collection stream() and parallel() In-Reply-To: References: <50C656FA.4060006@oracle.com> Message-ID: <50C65D7F.5020604@oracle.com> I understand your frustration with the oddly-overlapping participation mechanisms. But there is a suported mechanism for what you want -- the -comments list. The deal with the -comments lists is: - You write a self-contained, reasoned analysis containing your feedback - In turn, we commit to reviewing and discussing your feedback. What the -comments list doesn't do is provide a forum for open-ended, back-and-forth discussion. In exchange, you get a higher level of service. The -observers list is a place to have those open-ended discussions -- but given the higher noise level that is likely to ensue, the EG makes a lower committment to following it. This list is for discussions of the *implementation*, and for discussion of user experience with the code as it is. Sometimes the boundary between implementation and design is fuzzy. We try to err on the side of not getting too bent out of shape when someone accidentally steps over that line, but the risk is that the conversation spirals off into an open-ended design discussion, at which point it may get shut down. Hope this helps, -Brian On 12/10/2012 4:49 PM, Paul Benedict wrote: > Brian, can I post my suggestion here or must I subscribe to > lambda-libs-spec-observers at openjdk.java.net? > > PS: The problem with ALL observers list is that they are totally > worthless, in my opinion, because they all warn "EG members are under > no obligation to follow the traffic on this list". If I post there, it > sounds like no one will read them to reply -- so I feel I am writing > into a black hole. > > Paul > > On Mon, Dec 10, 2012 at 3:41 PM, Brian Goetz wrote: >> This is under discussion in the EG now. >> >> >> On 12/10/2012 4:09 PM, Paul Benedict wrote: >>> >>> I was surprised to see both these methods return Streams with such >>> wildly different method names. After seeing stream(), I was not >>> expecting another method to return streams -- it seemed like the >>> former was the "de facto" way of getting one. >>> >>> Would you consider perhaps renaming them? Something akin to >>> serialStream() and parallelStream()? Or streamSerially() and >>> streamParallely()? >>> >>> Paul >>> >> From robert.field at oracle.com Mon Dec 10 14:22:18 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Mon, 10 Dec 2012 22:22:18 +0000 Subject: hg: lambda/lambda/jdk: Runtime support for Lambda serialization (per Brian) Message-ID: <20121210222238.1CBF24701E@hg.openjdk.java.net> Changeset: 8dca6929391a Author: rfield Date: 2012-12-10 14:21 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8dca6929391a Runtime support for Lambda serialization (per Brian) ! src/share/classes/java/lang/invoke/AbstractValidatingLambdaMetafactory.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/SerializedLambda.java ! src/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java From akhil.arora at oracle.com Mon Dec 10 15:45:27 2012 From: akhil.arora at oracle.com (Akhil Arora) Date: Mon, 10 Dec 2012 15:45:27 -0800 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50BFDC75.6000306@oracle.com> References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com> <50BFBC49.9020200@oracle.com> <50BFDC75.6000306@oracle.com> Message-ID: <50C67417.2030205@oracle.com> http://cr.openjdk.java.net/~akhil/8004201.2/webrev/ - replaced "Suitable for conversion as a method reference to functional interfaces such as ..." with @see java.util.function.BinaryOperator - javadoc - replaced 'a argument'/'another argument' with 'the first operand'/'the second operand' - did not widen return types - widening the return type makes these methods unusable as reducers, since BinaryOperator is declared T operate(T left, T right) Thanks On 12/05/2012 03:44 PM, Joseph Darcy wrote: > Akhil, > > In javadoc like this > > 298 * as {@code BinaryOperator<Boolean>}. > > you don't have to use "<" and the like inside {@code}; please change to > > 298 * as {@code BinaryOperator}. > > As a general comment, if the operations for primitive type Foo are put > into java.lang.Foo, then the type of the operation needs to be > explicitly represented in the expression calling the method (unless > static imports are used, etc.). Therefore, I suggest putting these sort > of static methods all into one class to allow overloading to do its > thing (java.lang.Operators?). Also, for methods like sum, I think it is > worth considering returning a larger type than the operands to avoid > problems from integer or floating-point overflow. For example, sum on > byte and short would return int, sun on int would return long, etc. > > As an aside, to get a numerically robust result, the summation logic > over a set of doubles needs to be more than just a set of raw double > additions, but that can be tackled later. > > Cheers, > > -Joe > > > On 12/5/2012 1:27 PM, Akhil Arora wrote: >> Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/ >> >> - delegate to Math.min/max for int/long/float/double >> - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor >> - removed Character variants of min/max/sum >> >> On 12/02/2012 05:50 PM, David Holmes wrote: >>> Hi Akhil, >>> >>> Is it really necessary/desirable to flag all of these as " Suitable for >>> conversion as a method reference to functional interfaces such as ..." ? >> Not necessary, but it does provide a hint as to their intended use to a >> casual browser of these docs. >> >>> This style: >>> >>> + * @param a a boolean argument. >>> + * @param b another boolean argument. >>> >>> is at odds with the style used elsewhere for new Functional APIs, and >>> with the style of other methods in these classes. Can we just use "first >>> operand" and "second operand" for all of these? >> It is consistent with Math.min/max, which use the a/b style. Since these >> methods are not in one of the functional package, is'nt it better to >> stick to the local style? >> >>> Character.sum does not make sense to me. Who adds together characters? >>> I'm not even sure min and max are worth supporting for Character. >> Good point - removed these methods for Character. >> >>> I disagree with other suggestions to use the Math functions for >>> float/double. I think all these methods should use the underlying >>> primitive operator regardless of type. >> Are you disagreeing only for float/double or for int/long also? Can you >> provide more information as to why you disagree? >> >> Thanks >> >>> Thanks, >>> David >>> ----- >>> >>> On 1/12/2012 4:44 AM, Akhil Arora wrote: >>>> Hi >>>> >>>> Requesting review for some basic functionality related to lambdas - >>>> >>>> Add min, max, sum methods to the primitive wrapper classes - Byte, >>>> Short, Integer, Long, Float, Double and Character so as to be able to >>>> use them as reducers in lambda expressions. Add and, or, xor methods to >>>> Boolean. >>>> >>>> http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ >>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201 >>>> >>>> Thanks >> > From Robert.Field at oracle.com Mon Dec 10 15:49:01 2012 From: Robert.Field at oracle.com (Robert Field) Date: Mon, 10 Dec 2012 15:49:01 -0800 Subject: RFR: 8001647: In-place methods on Collection/List In-Reply-To: <65E39782-6530-47CB-A1FC-741A5B9ED4E2@oracle.com> References: <50C29B04.5070508@oracle.com> <50C5E36B.2040005@oracle.com> <65E39782-6530-47CB-A1FC-741A5B9ED4E2@oracle.com> Message-ID: <50C674ED.6030401@oracle.com> On 12/10/12 1:59 PM, Mike Duigou wrote: > On Dec 10 2012, at 05:28 , Alan Bateman wrote: > >> On 08/12/2012 01:42, Akhil Arora wrote: >>> As part of the Library Lambdafication, this patch adds the following >>> default methods to Collections - >>> >> This may be bikeshed territory but we usually don't use the "public" modifier on methods defined by interfaces as they are public anyway. > Adding "public" was at my suggestion. > >> It seems inconsistent to me to have it on the default methods. Perhaps this has been discussed before, in which case ignore this. BTW: The only reason I'm bringing this up is because there are lots of default methods to come and it would be nice to establish a convention and consistency from the start. > Agreed that we should be consistent. The suggestion to add "public" isn't related specifically to the default but anticipates, perhaps prematurely, future addition of "package" "module" and "protected" modifiers. When those modifiers are added it will make sense to be explicit about the access of a method. Maybe, maybe not, but at that point, if we want to be explicit, it should be on everything. Doing it now just on new stuff in anticipation of a possible change seems premature. > Additionally, some have complained about the difference in default access between interfaces and classes (public vs package) and prefer to explicit so that the intent is obvious and that method signature text in interfaces and classes look the same. Frankly, that argument seems silly as that distinction is true of all methods, not just default methods. -Robert > > So, worthwhile or not? > > Mike > From forax at univ-mlv.fr Mon Dec 10 16:35:34 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 11 Dec 2012 01:35:34 +0100 Subject: Feedback on the implementation of StringJoiner In-Reply-To: References: <50B8D792.9060601@oracle.com> Message-ID: <50C67FD6.2040808@univ-mlv.fr> On 12/10/2012 05:26 PM, Henry Jen wrote: > Hi Roel, > > I am doing some changes to adapt your feedbacks and trying to have minimum but enough APIs, latest proposed can be found at > > http://cr.openjdk.java.net/~henryjen/lambda/StringJoiner.1/webrev/ > > - remove add(CharSequence...) and add(char[]) from StringJoiner > - make StringJoiner(CharSequence) public and return StringJoiner. This > should be enough to cover cases where stream not available and we just > want to concat a few items. Also this is the only form we need for > String.join() > - Remove [AbstractStringBuilder/StringBuilder/StringBuffer].join(), in > favor of .append(String.join(..)). Essentially the same and API is more > comprehensive. > - Disallow null container(Iterable, Stream, varargs, etc), tolerate > container to have null content. > > Feel free to send your feedbacks. Thanks for the review. Henry, I'm sorry but this implementation is just horrible ... A StringJoiner is something which is able to concatenate String but wait, it's also a CharSequence too. Why using inheritance over composition here, if you want a CharSequence, why not having a method toCharSequence() I don't see myself why StringJoiner need to return a CharSequence given that String is a CharSequence. CharSequence is interresting when you take it as parameter but when you return it (or worst implement it), what is the gain ? So the conception is awful, and the implementation is awful too. Let say I just want to add a String and call toString, add will put the String into the StringBuilder, Ok and toString(), surprise, toString execute value.toString() + suffix, + is implemented by creating a new StringBuilder and adding the two strings, so the code take the StringBuilder value, create a new String from it (the .toString()), create a new StringBuilder (the +) append the freshly created String into the StringBuilder, append the suffix into the StringBuilder and recreate a new String. If you count, you have all the chars of the StringBuilder that are copied 3 times. The right way to implement it is to use an ArrayList (or a dedicated list as the one recently puhed in the lambda repo) to store all the CharSequence that are added, and to also maintain the total number of chars, when toString is called, allocate one new char array with the size (total number of chars + (list.size() - 1) * delimiterSize + prefix and suffix size and then crawle the ArrayList and store each CharSequence at the right place. > > Cheers, > Henry R?mi > > On Dec 10, 2012, at 1:59 AM, Roel Spilker wrote: > >> I understand. If I can help in any way, please let me know. I did sign an >> OCA 10 days ago, however, I don't know if it has been processed. >> >> >> On Fri, Nov 30, 2012 at 4:58 PM, Jim Gish wrote: >> >>> Hi Roel, >>> >>> I'll take a look. Sorry for the delay -- got pulled into other things. >>> >>> Jim >>> >>> On 11/28/2012 02:41 PM, Roel Spilker wrote: >>> >>>> Hi all, >>>> >>>> On June 25 I sent some feedback on the implementation of StringJoiner. >>>> Most >>>> of it is still relevant, none of it is addressed. Is there anything I can >>>> do to get the implementation to a higher level? >>>> >>>> Roel >>>> >>>> Thread containing the feedback >>>> http://mail.openjdk.java.net/**pipermail/lambda-dev/2012-** >>>> June/005078.html >>>> >>>> Link to the current implementation >>>> http://hg.openjdk.java.net/**lambda/lambda/jdk/file/** >>>> 83923cc50252/src/share/**classes/java/util/**StringJoiner.java >>>> >>>> >>> -- >>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >>> Oracle Java Platform Group | Core Libraries Team >>> 35 Network Drive >>> Burlington, MA 01803 >>> jim.gish at oracle.com >>> >>> > From henry.jen at oracle.com Mon Dec 10 18:16:01 2012 From: henry.jen at oracle.com (Henry Jen) Date: Mon, 10 Dec 2012 18:16:01 -0800 Subject: Feedback on the implementation of StringJoiner In-Reply-To: <50C67FD6.2040808@univ-mlv.fr> References: <50B8D792.9060601@oracle.com> <50C67FD6.2040808@univ-mlv.fr> Message-ID: <50C69761.8050400@oracle.com> Hi Remi, First of all, thanks for review. Comments inline. On 12/10/2012 04:35 PM, Remi Forax wrote: > On 12/10/2012 05:26 PM, Henry Jen wrote: >> Hi Roel, >> >> http://cr.openjdk.java.net/~henryjen/lambda/StringJoiner.1/webrev/ >>> > A StringJoiner is something which is able to concatenate String but > wait, it's also a CharSequence too. > Why using inheritance over composition here, if you want a CharSequence, > why not having a method toCharSequence() > I don't see myself why StringJoiner need to return a CharSequence given > that String is a CharSequence. > I am not sure why it was implemented this way, I am assuming StringJoiner would like to implement CharSequence API without actually call toString() for reasons you mentioned regrading performance. I have no issue to remove CharSequence interface, also, I think there are some more methods can be removed. > CharSequence is interresting when you take it as parameter but when you > return it (or worst implement it), > what is the gain ? > > So the conception is awful, and the implementation is awful too. > > Let say I just want to add a String and call toString, add will put the > String into the StringBuilder, Ok and toString(), surprise, toString > execute value.toString() + suffix, + is implemented by creating a new > StringBuilder and adding the two strings, so the code take the > StringBuilder value, create a new String from it (the .toString()), > create a new StringBuilder (the +) append the freshly created String > into the StringBuilder, append the suffix into the StringBuilder and > recreate a new String. If you count, you have all the chars of the > StringBuilder that are copied 3 times. > So the complain is the extra instance of StringBuilder with concatenation of suffix involved in toString(). I doubt we can implement a better version just do allocation and copy, and I am not sure that worth the effort. I am assuming that will be optimized by VM to concat two immutable string. Noted that, we will have to add suffix only when toString() is called, but keeps the state of StringJoiner for more item to be added. So toString() will make the concatenation of suffix. Now, for each add, we are using the same StringBuilder for appending, so I don't think there is much problems. > The right way to implement it is to use an ArrayList (or a dedicated > list as the one recently puhed in the lambda repo) to store all the > CharSequence that are added, and to also maintain the total number of > chars, when toString is called, allocate one new char array with the > size (total number of chars + (list.size() - 1) * delimiterSize + > prefix and suffix size and then crawle the ArrayList and store each > CharSequence at the right place. > The add will make copy(optimized by StringBuilder.append) of the string, so using a dedicate list, to my understanding, is no better than StringBuilder.append. If we don't make a copy, the behavior become nondeterministic depending on what CharSequence is passed as argument, which is confusing and inconsistent, thus I don't think that was the goal. Let me know ideas on improvement, I am all ears. Cheers, Henry From brian.goetz at oracle.com Mon Dec 10 18:58:41 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 11 Dec 2012 02:58:41 +0000 Subject: hg: lambda/lambda/jdk: Augment SequentialOpTest; fix bug in WrappingSpliterator Message-ID: <20121211025902.865B847037@hg.openjdk.java.net> Changeset: 6fffa407186c Author: briangoetz Date: 2012-12-10 21:56 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6fffa407186c Augment SequentialOpTest; fix bug in WrappingSpliterator ! src/share/classes/java/util/stream/StreamShapeFactory.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SequentialOpTest.java From mike.duigou at oracle.com Mon Dec 10 19:28:47 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 11 Dec 2012 03:28:47 +0000 Subject: hg: lambda/lambda/jdk: minor corrections Message-ID: <20121211032858.C099E47038@hg.openjdk.java.net> Changeset: 3bd4bd1d3a7e Author: mduigou Date: 2012-12-10 17:11 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3bd4bd1d3a7e minor corrections ! src/share/classes/java/util/function/IntBlock.java ! test/java/util/function/PredicateTest.java From brian.goetz at oracle.com Mon Dec 10 19:48:11 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 11 Dec 2012 03:48:11 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121211034833.BBD7E47039@hg.openjdk.java.net> Changeset: 1a5733965535 Author: briangoetz Date: 2012-12-10 22:47 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1a5733965535 Add .parallel() op on Stream and IntStream ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntStream.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SequentialOpTest.java Changeset: 157a6605dec6 Author: briangoetz Date: 2012-12-10 22:48 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/157a6605dec6 Merge From brian.goetz at oracle.com Mon Dec 10 20:00:05 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 11 Dec 2012 04:00:05 +0000 Subject: hg: lambda/lambda/jdk: Simple test for parallel stream generators Message-ID: <20121211040017.080BF4703A@hg.openjdk.java.net> Changeset: 0132ff879cea Author: briangoetz Date: 2012-12-10 23:00 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0132ff879cea Simple test for parallel stream generators + test-ng/tests/org/openjdk/tests/java/util/stream/ParallelRangeTest.java From brian.goetz at oracle.com Mon Dec 10 20:19:26 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 11 Dec 2012 04:19:26 +0000 Subject: hg: lambda/lambda/jdk: Replace Combiner with BiFunction; eliminate field sourceShape of AbstractPipeline Message-ID: <20121211041940.6AC954703C@hg.openjdk.java.net> Changeset: 433c67388856 Author: briangoetz Date: 2012-12-10 23:19 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/433c67388856 Replace Combiner with BiFunction; eliminate field sourceShape of AbstractPipeline ! src/share/classes/java/util/function/BinaryOperator.java - src/share/classes/java/util/function/Combiner.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/op/FoldOp.java ! src/share/classes/java/util/stream/op/ReduceByOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ReduceTest.java From akhil.arora at oracle.com Mon Dec 10 21:31:08 2012 From: akhil.arora at oracle.com (Akhil Arora) Date: Mon, 10 Dec 2012 21:31:08 -0800 Subject: RFR: 8001647: In-place methods on Collection/List In-Reply-To: <50C658A9.30607@oracle.com> References: <50C34AAE.4498.1080E1A4@v.a.ammodytes.googlemail.com> <50C658A9.30607@oracle.com> Message-ID: <50C6C51C.8080903@oracle.com> http://cr.openjdk.java.net/~akhil/8001647.3/webrev/ - now with synchronized and unmodifiable wrappers in Collections.java for the default methods being added On 12/10/2012 01:48 PM, Akhil Arora wrote: > Updated with yours and Alan's comments - > > http://cr.openjdk.java.net/~akhil/8001647.2/webrev/ > > - removed null check for removeSet > - cache this.size in removeAll, replaceAll > (for ArrayList, Vector and CopyOnWriteArrayList) > - calculate removeCount instead of BitCount.cardinality() > - removed unnecessary @library from test support classes > > Catching IndexOOB and throwing CME in forEach/removeAll/replaceAll seems > unecessary... did you have a use-case in mind where an IndexOOB can > occur with these methods? > > Thanks > > On 12/08/2012 05:11 AM, Arne Siegel wrote: >> ArrayList.java, line 1171: >> final boolean anyToRemove = (removeSet != null) && !removeSet.isEmpty(); >> As removeSet will never be null, this line can be simplified. This is a left-over from the >> preceding implementation (see b67). >> >> ArrayList.java, method forEach optimizes the loop by reducing the number of heap accesses: >> final int size = this.size; >> for (int i=0; modCount == expectedModCount && i < size; i++) { >> ... >> This trick might also be introduced to methods removeAll and replaceAll. >> >> In the ListIterator implementation of ArrayList, there are various appearances of the idiom: >> try { >> ... >> } catch (IndexOutOfBoundsException ex) { >> throw new ConcurrentModificationException(); >> } >> This technique might also be used in forEach, removeAll, and replaceAll (though not likely to >> be of any importance). >> >> Regards >> Arne Siegel >> > > From fsarradin at gmail.com Mon Dec 10 22:07:45 2012 From: fsarradin at gmail.com (=?ISO-8859-1?Q?Fran=E7ois_Sarradin?=) Date: Tue, 11 Dec 2012 07:07:45 +0100 Subject: Stream from Iterable Message-ID: Hi, Is there a way to get a Stream from an Iterable with the update b67? Should I create a Collection first or is there something shorter? Regards, Fran?ois Sarradin From forax at univ-mlv.fr Tue Dec 11 00:08:03 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 11 Dec 2012 09:08:03 +0100 Subject: Feedback on the implementation of StringJoiner In-Reply-To: <50C69761.8050400@oracle.com> References: <50B8D792.9060601@oracle.com> <50C67FD6.2040808@univ-mlv.fr> <50C69761.8050400@oracle.com> Message-ID: <50C6E9E3.4000506@univ-mlv.fr> On 12/11/2012 03:16 AM, Henry Jen wrote: > Hi Remi, Hi Henry, > > First of all, thanks for review. Comments inline. > > On 12/10/2012 04:35 PM, Remi Forax wrote: >> On 12/10/2012 05:26 PM, Henry Jen wrote: >>> Hi Roel, >>> >>> http://cr.openjdk.java.net/~henryjen/lambda/StringJoiner.1/webrev/ >> A StringJoiner is something which is able to concatenate String but >> wait, it's also a CharSequence too. >> Why using inheritance over composition here, if you want a CharSequence, >> why not having a method toCharSequence() >> I don't see myself why StringJoiner need to return a CharSequence given >> that String is a CharSequence. >> > I am not sure why it was implemented this way, I am assuming > StringJoiner would like to implement CharSequence API without actually > call toString() for reasons you mentioned regrading performance. > > I have no issue to remove CharSequence interface, also, I think there > are some more methods can be removed. > >> CharSequence is interresting when you take it as parameter but when you >> return it (or worst implement it), >> what is the gain ? >> >> So the conception is awful, and the implementation is awful too. >> >> Let say I just want to add a String and call toString, add will put the >> String into the StringBuilder, Ok and toString(), surprise, toString >> execute value.toString() + suffix, + is implemented by creating a new >> StringBuilder and adding the two strings, so the code take the >> StringBuilder value, create a new String from it (the .toString()), >> create a new StringBuilder (the +) append the freshly created String >> into the StringBuilder, append the suffix into the StringBuilder and >> recreate a new String. If you count, you have all the chars of the >> StringBuilder that are copied 3 times. >> > So the complain is the extra instance of StringBuilder with > concatenation of suffix involved in toString(). I doubt we can implement > a better version just do allocation and copy, and I am not sure that > worth the effort. I am assuming that will be optimized by VM to concat > two immutable string. toString() load the StringBuilder (value) from a field, the VM will be able to do something only if it can prove that the StringJoiner doesn't escape. This mean that the VM is able to inline the whole stream pipeline. While it's doable in the future, we are far from that point. The optimization the VM does is to avoid to create the intermediary StringBuilder but not the intermediary array of chars. > > Noted that, we will have to add suffix only when toString() is called, > but keeps the state of StringJoiner for more item to be added. So > toString() will make the concatenation of suffix. yes, that the intended semantics. > > Now, for each add, we are using the same StringBuilder for appending, so > I don't think there is much problems. so you ask to copy the chars of the String in the StringBuilder, which is not necessary see below. > >> The right way to implement it is to use an ArrayList (or a dedicated >> list as the one recently puhed in the lambda repo) to store all the >> CharSequence that are added, and to also maintain the total number of >> chars, when toString is called, allocate one new char array with the >> size (total number of chars + (list.size() - 1) * delimiterSize + >> prefix and suffix size and then crawle the ArrayList and store each >> CharSequence at the right place. >> > The add will make copy(optimized by StringBuilder.append) of the string, > so using a dedicate list, to my understanding, is no better than > StringBuilder.append. > > If we don't make a copy, the behavior become nondeterministic depending > on what CharSequence is passed as argument, which is confusing and > inconsistent, thus I don't think that was the goal. yes, you have to call toString() before storing it in the ArrayList of String but a stream of CharSequence has the very same issue so I don't expect people will use a stream of CharSequence that are not String very often so the copy is not needed in more than 80% of the use cases. so to summarize, using an ArrayList is better than a StringBuilder because most of the time we will join strings. > > Let me know ideas on improvement, I am all ears. > > Cheers, > Henry > cheers, R?mi From boaznahum at gmail.com Tue Dec 11 00:15:37 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Tue, 11 Dec 2012 10:15:37 +0200 Subject: hg: lambda/lambda/langtools: Fix: Add extra checks when lambda/method ref is converted to intersection type In-Reply-To: <50C60599.3030602@oracle.com> References: <20121128103215.E2D0947B6F@hg.openjdk.java.net> <50C60599.3030602@oracle.com> Message-ID: Thanks for the explanation On Dec 10, 2012 5:54 PM, "Maurizio Cimadamore" < maurizio.cimadamore at oracle.com> wrote: > On 28/11/12 18:41, Boaz Nahum wrote: > >> Can you explain why? >> If I1 and I2 have same SAM why (I1 & I2) is not valid? >> Can also explain why the order does matter? >> > I forgot to reply on this one - the idea is that type-erasuer already > introduce order-dependency on intersection types (i.e. the erasure of A & B > & C is A). So it makes sense to give special properties to the first type > of an intersection in the context of a SAM conversion. > > Maurizio > > Thx >> (sorry foy English ) >> Boaz >> On Nov 28, 2012 12:34 PM, > >> wrote: >> >> Changeset: 7fa8e7c02baa >>> Author: mcimadamore >>> Date: 2012-11-28 10:31 +0000 >>> URL: >>> http://hg.openjdk.java.net/**lambda/lambda/langtools/rev/**7fa8e7c02baa >>> >>> Fix: Add extra checks when lambda/method ref is converted to intersection >>> type >>> >>> A lambda/methdod reference can be converted to an intersection type >>> provided that: >>> >>> *) All types in the intersection are interface types >>> *) The first type of the intersection is a functional interface >>> *) The additional bounds of the intersection are marker interfaces >>> >>> ! 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/resources/** >>> compiler.properties >>> ! test/tools/javac/diags/**examples.not-yet.txt >>> + test/tools/javac/lambda/**intersection/**IntersectionTargetTypeTest.** >>> java >>> >>> >>> >>> > From scolebourne at joda.org Tue Dec 11 00:54:37 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 11 Dec 2012 08:54:37 +0000 Subject: Feedback on the implementation of StringJoiner In-Reply-To: References: <50B8D792.9060601@oracle.com> Message-ID: On 10 December 2012 16:26, Henry Jen wrote: > I am doing some changes to adapt your feedbacks and trying to have minimum but enough APIs, latest proposed can be found at > > http://cr.openjdk.java.net/~henryjen/lambda/StringJoiner.1/webrev/ StringJoiner Line 61 example - missing bracket ) First line of some method descriptions starts with lower case rather than upper. Line 260 exception not listed in Javadoc As a general rule, I would try very hard to return a String, not a CharSequence. Accepting a CharSequence on input is OK, but returning it gives very few guarantees to callers. Think Postels law. Stephen From aleksey.shipilev at oracle.com Tue Dec 11 01:39:57 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 11 Dec 2012 13:39:57 +0400 Subject: Par vs. Seq decomposition experiment update In-Reply-To: <50C60BEC.5010603@oracle.com> References: <50C607A1.2060608@oracle.com> <50C60BEC.5010603@oracle.com> Message-ID: <50C6FF6D.7030908@oracle.com> On 12/10/2012 08:21 PM, Brian Goetz wrote: > Has the N*Q isoline moved closer to the origin compared to previous > experiments? Short version: you might argue the answer is "yes". Long version: previous experiments were using "mean" as the primary metric, which involved GCs in the metric. If we compare the means for old experiment and the mean for new experiment, then we have up to ~10% improvement (e.g. 440us vs 400us now), but that could be easily hijacked by rogue GCs. We do know the new FJP answer for ~10-15% improvements in cold start scenarios, so this seems to be related. In any case, there seem to be nothing pathological with FJP at this point, and I should really focus to the internal lambda mechanics now. The benefits for isoline should be more fruitful there. > Separately, I have a good understanding of what N=10^3 means. But how > much "real computation" does Q=10^2 mean? You can easily infer that. With N=10^3 and Q=10^2, seq runs the job at 450us. Assuming the absence of pipelining effects (very crude), we can figure out N=1, Q=1 is closer to 4.5ns. From the code perspective, the elementary operation corresponding to Q=1 is just a simple multiply-add-mask, and it takes around 10 cycles per op. -Aleksey. From david.holmes at oracle.com Tue Dec 11 03:41:00 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 11 Dec 2012 21:41:00 +1000 Subject: RFR: 8001647: In-place methods on Collection/List In-Reply-To: <65E39782-6530-47CB-A1FC-741A5B9ED4E2@oracle.com> References: <50C29B04.5070508@oracle.com> <50C5E36B.2040005@oracle.com> <65E39782-6530-47CB-A1FC-741A5B9ED4E2@oracle.com> Message-ID: <50C71BCC.9060205@oracle.com> On 11/12/2012 7:59 AM, Mike Duigou wrote: > > On Dec 10 2012, at 05:28 , Alan Bateman wrote: > >> On 08/12/2012 01:42, Akhil Arora wrote: >>> As part of the Library Lambdafication, this patch adds the following >>> default methods to Collections - >>> >> This may be bikeshed territory but we usually don't use the "public" modifier on methods defined by interfaces as they are public anyway. > > Adding "public" was at my suggestion. > >> It seems inconsistent to me to have it on the default methods. Perhaps this has been discussed before, in which case ignore this. BTW: The only reason I'm bringing this up is because there are lots of default methods to come and it would be nice to establish a convention and consistency from the start. > > Agreed that we should be consistent. The suggestion to add "public" isn't related specifically to the default but anticipates, perhaps prematurely, future addition of "package" "module" and "protected" modifiers. When those modifiers are added it will make sense to be explicit about the access of a method. Additionally, some have complained about the difference in default access between interfaces and classes (public vs package) and prefer to explicit so that the intent is obvious and that method signature text in interfaces and classes look the same. > > So, worthwhile or not? I think not. No matter what modifiers come in the future the default will always have to remain "public". But if you are going to add it then add it to all the methods in the interfaces being updated. David ----- > Mike > From Alan.Bateman at oracle.com Tue Dec 11 04:28:38 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Dec 2012 12:28:38 +0000 Subject: RFR: 8001647: In-place methods on Collection/List In-Reply-To: <65E39782-6530-47CB-A1FC-741A5B9ED4E2@oracle.com> References: <50C29B04.5070508@oracle.com> <50C5E36B.2040005@oracle.com> <65E39782-6530-47CB-A1FC-741A5B9ED4E2@oracle.com> Message-ID: <50C726F6.8020203@oracle.com> On 10/12/2012 21:59, Mike Duigou wrote: > : > > Adding "public" was at my suggestion. > >> It seems inconsistent to me to have it on the default methods. Perhaps this has been discussed before, in which case ignore this. BTW: The only reason I'm bringing this up is because there are lots of default methods to come and it would be nice to establish a convention and consistency from the start. > Agreed that we should be consistent. The suggestion to add "public" isn't related specifically to the default but anticipates, perhaps prematurely, future addition of "package" "module" and "protected" modifiers. When those modifiers are added it will make sense to be explicit about the access of a method. Additionally, some have complained about the difference in default access between interfaces and classes (public vs package) and prefer to explicit so that the intent is obvious and that method signature text in interfaces and classes look the same. > > So, worthwhile or not? It's probably not worth spending time on now but if we going to be explicit with new methods then existing methods should be updated too. -Alan. From paul.sandoz at oracle.com Tue Dec 11 05:04:47 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 11 Dec 2012 13:04:47 +0000 Subject: hg: lambda/lambda/jdk: - Add int-specific spliterator data provider and tests Message-ID: <20121211130546.5043D47055@hg.openjdk.java.net> Changeset: 231137eba17f Author: psandoz Date: 2012-12-11 14:04 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/231137eba17f - Add int-specific spliterator data provider and tests - Improve permutation of operations for stream spliterator tests - Fix issues with ConcNode spliterator ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java From paul.sandoz at oracle.com Tue Dec 11 05:33:28 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 11 Dec 2012 13:33:28 +0000 Subject: hg: lambda/lambda/jdk: - Data provider for int range spliterator Message-ID: <20121211133352.A571847056@hg.openjdk.java.net> Changeset: 6f6dd4119e05 Author: psandoz Date: 2012-12-11 14:33 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6f6dd4119e05 - Data provider for int range spliterator - Fix known size of int range spliterator ! src/share/classes/java/util/stream/primitive/Primitives.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java From brian.goetz at oracle.com Tue Dec 11 06:29:20 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 11 Dec 2012 09:29:20 -0500 Subject: Stream from Iterable In-Reply-To: References: Message-ID: <50C74340.8090505@oracle.com> Try this: Streams.stream(Streams.spliterator(iter.iterator(), sizeIfKnown), flags); You might want ORDERED as a flag. On 12/11/2012 1:07 AM, Fran?ois Sarradin wrote: > Hi, > > Is there a way to get a Stream from an Iterable with the update b67? > > Should I create a Collection first or is there something shorter? > > Regards, > Fran?ois Sarradin > From paul.sandoz at oracle.com Tue Dec 11 06:38:00 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 11 Dec 2012 14:38:00 +0000 Subject: hg: lambda/lambda/jdk: - Add int stream data providers for range Message-ID: <20121211143824.0D54547059@hg.openjdk.java.net> Changeset: 190371432071 Author: psandoz Date: 2012-12-11 15:37 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/190371432071 - Add int stream data providers for range - Fix bug calculating the mid point for spliting of a range. ! src/share/classes/java/util/stream/primitive/Primitives.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java From paul.sandoz at oracle.com Tue Dec 11 07:04:48 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 11 Dec 2012 15:04:48 +0000 Subject: hg: lambda/lambda/jdk: Ensure consumed and linked state are correct for creation Message-ID: <20121211150513.9869B4705B@hg.openjdk.java.net> Changeset: 2440c2c57d7e Author: psandoz Date: 2012-12-11 16:04 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2440c2c57d7e Ensure consumed and linked state are correct for creation of new pipeline chain with stateful op. ! src/share/classes/java/util/stream/AbstractPipeline.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamReuseTest.java From brian.goetz at oracle.com Tue Dec 11 07:23:44 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Tue, 11 Dec 2012 15:23:44 +0000 Subject: hg: lambda/lambda/jdk: Additional cleanup on AbstractPipeline.sourceShape Message-ID: <20121211152403.46F484705E@hg.openjdk.java.net> Changeset: 1c7656355153 Author: briangoetz Date: 2012-12-11 10:23 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1c7656355153 Additional cleanup on AbstractPipeline.sourceShape ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java From scolebourne at joda.org Tue Dec 11 07:27:24 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 11 Dec 2012 15:27:24 +0000 Subject: Stream from Iterable In-Reply-To: <50C74340.8090505@oracle.com> References: <50C74340.8090505@oracle.com> Message-ID: On 11 December 2012 14:29, Brian Goetz wrote: > Try this: > > Streams.stream(Streams.spliterator(iter.iterator(), sizeIfKnown), > flags); > > You might want ORDERED as a flag. That seems quite verbose for what seems like a common operation... Stephen From forax at univ-mlv.fr Tue Dec 11 08:00:56 2012 From: forax at univ-mlv.fr (=?utf-8?B?UmVtaSBGb3JheA==?=) Date: Tue, 11 Dec 2012 17:00:56 +0100 Subject: =?utf-8?B?UmU6IFN0cmVhbSBmcm9tIEl0ZXJhYmxl?= Message-ID: <201212111600.qBBG0ppo007554@monge.univ-mlv.fr> That's the entrypoint. In my opinion we need to add a default method stream() on Iterator. Sent from my Phone ----- Reply message ----- From: "Stephen Colebourne" To: "lambda-dev" Subject: Stream from Iterable Date: Tue, Dec 11, 2012 16:27 On 11 December 2012 14:29, Brian Goetz wrote: > Try this: > > Streams.stream(Streams.spliterator(iter.iterator(), sizeIfKnown), > flags); > > You might want ORDERED as a flag. That seems quite verbose for what seems like a common operation... Stephen From brian.goetz at oracle.com Tue Dec 11 08:06:21 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 11 Dec 2012 11:06:21 -0500 Subject: Stream from Iterable In-Reply-To: References: <50C74340.8090505@oracle.com> Message-ID: <50C759FD.8030204@oracle.com> I do not expect this to be a common operation; clients will obtains streams by calling the stream() method on a Streamable. This technique is a lower-level API for *implementors* of Streamable. And I think you'll agree that this is far, far less verbose than what you have to do to implement Iterable... The #1 source of Iterables is Collections. All the Collections have stream() methods; their implementations are one-liners like this one. Actually, this is one of the weaker ways to implement a Stream; if you have a real data structure, you'll probably want to implement Spliterator. But if all you have is an Iterator, we can turn it into a stream for you. On 12/11/2012 10:27 AM, Stephen Colebourne wrote: > On 11 December 2012 14:29, Brian Goetz wrote: >> Try this: >> >> Streams.stream(Streams.spliterator(iter.iterator(), sizeIfKnown), >> flags); >> >> You might want ORDERED as a flag. > > That seems quite verbose for what seems like a common operation... > > Stephen > From scolebourne at joda.org Tue Dec 11 08:18:00 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 11 Dec 2012 16:18:00 +0000 Subject: Stream from Iterable In-Reply-To: <50C759FD.8030204@oracle.com> References: <50C74340.8090505@oracle.com> <50C759FD.8030204@oracle.com> Message-ID: The latest code in hg has no stream() method on Iterable. That feels wrong. I have on a number of occasions defined an API to accept Iterable when I don't care what type of collection it is. It is more friendly to users that way. Those APIs will have no easy way to transition to streams (the code you pasted is not easy). I'm assuming that the decision to not implement Streamable on Iterable was deliberate, just saying that it degardes the usefulness of Iterable (and its an interface that the JDK has never fully embraced). Stephen On 11 December 2012 16:06, Brian Goetz wrote: > I do not expect this to be a common operation; clients will obtains streams > by calling the stream() method on a Streamable. This technique is a > lower-level API for *implementors* of Streamable. And I think you'll agree > that this is far, far less verbose than what you have to do to implement > Iterable... > > The #1 source of Iterables is Collections. All the Collections have > stream() methods; their implementations are one-liners like this one. > > Actually, this is one of the weaker ways to implement a Stream; if you have > a real data structure, you'll probably want to implement Spliterator. But > if all you have is an Iterator, we can turn it into a stream for you. > > > On 12/11/2012 10:27 AM, Stephen Colebourne wrote: >> >> On 11 December 2012 14:29, Brian Goetz wrote: >>> >>> Try this: >>> >>> Streams.stream(Streams.spliterator(iter.iterator(), sizeIfKnown), >>> flags); >>> >>> You might want ORDERED as a flag. >> >> >> That seems quite verbose for what seems like a common operation... >> >> Stephen >> > From brian.goetz at oracle.com Tue Dec 11 08:45:16 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 11 Dec 2012 11:45:16 -0500 Subject: Stream from Iterable In-Reply-To: References: <50C74340.8090505@oracle.com> <50C759FD.8030204@oracle.com> Message-ID: <50C7631C.1030409@oracle.com> Stepping back... There are lots of ways to create a Stream. The more information you have about how to describe the elements, the more functionality and performance the streams library can give you. In order of least to most information, they are: Iterator Iterator + size Spliterator Spliterator that knows its size Spliterator that knows its size, and further knows that all sub-splits know their size. (Some may be surprised to find that we can extract parallelism even from a dumb iterator in cases where Q (work per element) is nontrivial.) If Iterable had a stream() method, it would just wrap an Iterator with a Spliterator, with no size information. But, most things that are Iterable *do* have size information. Which means we're serving up deficient streams. That's not so good. One downside of the API practice outlined by Stephen here, of accepting Iterable instead of Collection, is that you are forcing things through a "small pipe" and therefore discarding size information when it might be useful. That's fine if all you're doing to do is forEach it, but if you want to do more, its better if you can preserve all the information you want. The default provided by Iterable would be a crappy one indeed -- it would discard size even though the vast majority of Iterables do know that information. On 12/11/2012 11:18 AM, Stephen Colebourne wrote: > The latest code in hg has no stream() method on Iterable. That feels wrong. > > I have on a number of occasions defined an API to accept Iterable when > I don't care what type of collection it is. It is more friendly to > users that way. Those APIs will have no easy way to transition to > streams (the code you pasted is not easy). > > I'm assuming that the decision to not implement Streamable on Iterable > was deliberate, just saying that it degardes the usefulness of > Iterable (and its an interface that the JDK has never fully embraced). > > Stephen > > > On 11 December 2012 16:06, Brian Goetz wrote: >> I do not expect this to be a common operation; clients will obtains streams >> by calling the stream() method on a Streamable. This technique is a >> lower-level API for *implementors* of Streamable. And I think you'll agree >> that this is far, far less verbose than what you have to do to implement >> Iterable... >> >> The #1 source of Iterables is Collections. All the Collections have >> stream() methods; their implementations are one-liners like this one. >> >> Actually, this is one of the weaker ways to implement a Stream; if you have >> a real data structure, you'll probably want to implement Spliterator. But >> if all you have is an Iterator, we can turn it into a stream for you. >> >> >> On 12/11/2012 10:27 AM, Stephen Colebourne wrote: >>> >>> On 11 December 2012 14:29, Brian Goetz wrote: >>>> >>>> Try this: >>>> >>>> Streams.stream(Streams.spliterator(iter.iterator(), sizeIfKnown), >>>> flags); >>>> >>>> You might want ORDERED as a flag. >>> >>> >>> That seems quite verbose for what seems like a common operation... >>> >>> Stephen >>> >> > From zhong.j.yu at gmail.com Tue Dec 11 09:06:10 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Tue, 11 Dec 2012 11:06:10 -0600 Subject: Stream from Iterable In-Reply-To: <50C7631C.1030409@oracle.com> References: <50C74340.8090505@oracle.com> <50C759FD.8030204@oracle.com> <50C7631C.1030409@oracle.com> Message-ID: For existing APIs that accept Iterables, information is already lost, the default/crappy implementation of stream() is the best one can do anyway. Going forward, should new APIs accept Streamables instead of Iterables? Streamable is kind of ugly though void accept(Streamable> foos) Zhong Yu On Tue, Dec 11, 2012 at 10:45 AM, Brian Goetz wrote: > Stepping back... > > There are lots of ways to create a Stream. The more information you > have about how to describe the elements, the more functionality and > performance the streams library can give you. In order of least to most > information, they are: > > Iterator > > Iterator + size > > Spliterator > > Spliterator that knows its size > > Spliterator that knows its size, and further knows that all sub-splits > know their size. > > (Some may be surprised to find that we can extract parallelism even from > a dumb iterator in cases where Q (work per element) is nontrivial.) > > > If Iterable had a stream() method, it would just wrap an Iterator with a > Spliterator, with no size information. But, most things that are > Iterable *do* have size information. Which means we're serving up > deficient streams. That's not so good. > > > One downside of the API practice outlined by Stephen here, of accepting > Iterable instead of Collection, is that you are forcing things through a > "small pipe" and therefore discarding size information when it might be > useful. That's fine if all you're doing to do is forEach it, but if you > want to do more, its better if you can preserve all the information you > want. > > The default provided by Iterable would be a crappy one indeed -- it > would discard size even though the vast majority of Iterables do know > that information. > > > > On 12/11/2012 11:18 AM, Stephen Colebourne wrote: >> The latest code in hg has no stream() method on Iterable. That feels wrong. >> >> I have on a number of occasions defined an API to accept Iterable when >> I don't care what type of collection it is. It is more friendly to >> users that way. Those APIs will have no easy way to transition to >> streams (the code you pasted is not easy). >> >> I'm assuming that the decision to not implement Streamable on Iterable >> was deliberate, just saying that it degardes the usefulness of >> Iterable (and its an interface that the JDK has never fully embraced). >> >> Stephen >> >> >> On 11 December 2012 16:06, Brian Goetz wrote: >>> I do not expect this to be a common operation; clients will obtains streams >>> by calling the stream() method on a Streamable. This technique is a >>> lower-level API for *implementors* of Streamable. And I think you'll agree >>> that this is far, far less verbose than what you have to do to implement >>> Iterable... >>> >>> The #1 source of Iterables is Collections. All the Collections have >>> stream() methods; their implementations are one-liners like this one. >>> >>> Actually, this is one of the weaker ways to implement a Stream; if you have >>> a real data structure, you'll probably want to implement Spliterator. But >>> if all you have is an Iterator, we can turn it into a stream for you. >>> >>> >>> On 12/11/2012 10:27 AM, Stephen Colebourne wrote: >>>> >>>> On 11 December 2012 14:29, Brian Goetz wrote: >>>>> >>>>> Try this: >>>>> >>>>> Streams.stream(Streams.spliterator(iter.iterator(), sizeIfKnown), >>>>> flags); >>>>> >>>>> You might want ORDERED as a flag. >>>> >>>> >>>> That seems quite verbose for what seems like a common operation... >>>> >>>> Stephen >>>> >>> >> > From pbenedict at apache.org Tue Dec 11 10:10:46 2012 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 11 Dec 2012 12:10:46 -0600 Subject: InfiniteIterator#hasNext() javadoc todo Message-ID: Unless there is a reason why it hasNext() should ever return false, this class should not inherit Iterator's doc. It should state it always returns true. Paul From julianhyde at gmail.com Tue Dec 11 11:25:45 2012 From: julianhyde at gmail.com (Julian Hyde) Date: Tue, 11 Dec 2012 11:25:45 -0800 Subject: Request for binary search using functions In-Reply-To: References: Message-ID: On Dec 9, 2012, at 8:48 PM, Cleber Muramoto wrote: > Hello, every once in a while I come across the problem of having to use an > incompatible key to perform a binary search, e.g.: > > int binarySearch(SimpleDateFormat[] array,String pattern){ > ... > String midVal = array[i].toPattern(); > ... > } > > (array is sorted using (l,r)->l.toPattern().compareTo(r.toPattern()) ) I think an AbstractList does the trick. It maps values to strings, and only incurs one allocation per search. You need to make it implement RandomAccess so that binarySearch uses an efficient algorithm. final SimpleDateFormat[] array; final String seek; class AbstractRandomAccessList extends AbstractList implements RandomAccess {}; return Collections.binarySearch( new AbstractRandomAccessList() { public int size() { return array.length; } public String get(int index) { return array[index].toPattern(); }, seek); There's also a variant Collections.binarySearch(Object[], int, int) if you wish to search on ranges. Aside: AbstractList is so useful; it's a shame it is a DAM and not a SAM, and therefore not eligible for lambdafication. Does anyone have any bright ideas how the above could be expressed in lambdas? Julian From akhil.arora at oracle.com Tue Dec 11 11:54:00 2012 From: akhil.arora at oracle.com (Akhil Arora) Date: Tue, 11 Dec 2012 11:54:00 -0800 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50C67417.2030205@oracle.com> References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com> <50BFBC49.9020200@oracle.com> <50BFDC75.6000306@oracle.com> <50C67417.2030205@oracle.com> Message-ID: <50C78F58.70705@oracle.com> http://cr.openjdk.java.net/~akhil/8004201.3/webrev/ - removed these operators on Byte and Short - javadoc improvements based on CCC review On 12/10/2012 03:45 PM, Akhil Arora wrote: > http://cr.openjdk.java.net/~akhil/8004201.2/webrev/ > > - replaced "Suitable for conversion as a method reference to functional > interfaces such as ..." with @see java.util.function.BinaryOperator > > - javadoc - replaced 'a argument'/'another argument' with > 'the first operand'/'the second operand' > > - did not widen return types - widening the return type makes these > methods unusable as reducers, since BinaryOperator is declared > T operate(T left, T right) > > Thanks > > On 12/05/2012 03:44 PM, Joseph Darcy wrote: >> Akhil, >> >> In javadoc like this >> >> 298 * as {@code BinaryOperator<Boolean>}. >> >> you don't have to use "<" and the like inside {@code}; please >> change to >> >> 298 * as {@code BinaryOperator}. >> >> As a general comment, if the operations for primitive type Foo are put >> into java.lang.Foo, then the type of the operation needs to be >> explicitly represented in the expression calling the method (unless >> static imports are used, etc.). Therefore, I suggest putting these sort >> of static methods all into one class to allow overloading to do its >> thing (java.lang.Operators?). Also, for methods like sum, I think it is >> worth considering returning a larger type than the operands to avoid >> problems from integer or floating-point overflow. For example, sum on >> byte and short would return int, sun on int would return long, etc. >> >> As an aside, to get a numerically robust result, the summation logic >> over a set of doubles needs to be more than just a set of raw double >> additions, but that can be tackled later. >> >> Cheers, >> >> -Joe >> >> >> On 12/5/2012 1:27 PM, Akhil Arora wrote: >>> Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/ >>> >>> - delegate to Math.min/max for int/long/float/double >>> - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor >>> - removed Character variants of min/max/sum >>> >>> On 12/02/2012 05:50 PM, David Holmes wrote: >>>> Hi Akhil, >>>> >>>> Is it really necessary/desirable to flag all of these as " Suitable for >>>> conversion as a method reference to functional interfaces such as >>>> ..." ? >>> Not necessary, but it does provide a hint as to their intended use to a >>> casual browser of these docs. >>> >>>> This style: >>>> >>>> + * @param a a boolean argument. >>>> + * @param b another boolean argument. >>>> >>>> is at odds with the style used elsewhere for new Functional APIs, and >>>> with the style of other methods in these classes. Can we just use >>>> "first >>>> operand" and "second operand" for all of these? >>> It is consistent with Math.min/max, which use the a/b style. Since these >>> methods are not in one of the functional package, is'nt it better to >>> stick to the local style? >>> >>>> Character.sum does not make sense to me. Who adds together characters? >>>> I'm not even sure min and max are worth supporting for Character. >>> Good point - removed these methods for Character. >>> >>>> I disagree with other suggestions to use the Math functions for >>>> float/double. I think all these methods should use the underlying >>>> primitive operator regardless of type. >>> Are you disagreeing only for float/double or for int/long also? Can you >>> provide more information as to why you disagree? >>> >>> Thanks >>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> On 1/12/2012 4:44 AM, Akhil Arora wrote: >>>>> Hi >>>>> >>>>> Requesting review for some basic functionality related to lambdas - >>>>> >>>>> Add min, max, sum methods to the primitive wrapper classes - Byte, >>>>> Short, Integer, Long, Float, Double and Character so as to be able to >>>>> use them as reducers in lambda expressions. Add and, or, xor >>>>> methods to >>>>> Boolean. >>>>> >>>>> http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ >>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201 >>>>> >>>>> Thanks >>> >> > From fsarradin at gmail.com Tue Dec 11 12:48:56 2012 From: fsarradin at gmail.com (=?ISO-8859-1?Q?Fran=E7ois_Sarradin?=) Date: Tue, 11 Dec 2012 21:48:56 +0100 Subject: Stream from Iterable In-Reply-To: <50C74340.8090505@oracle.com> References: <50C74340.8090505@oracle.com> Message-ID: In fact, I would like to performed bulk operations like map, reduce, or groupBy on iterables. With update b56, I usually use stream(iter) to get access to those operations. That's why my question was about Iterable into Stream. But is there another (simpler?) way to access those operations from an Iterable? 2012/12/11 Brian Goetz > Try this: > > Streams.stream(Streams.**spliterator(iter.iterator(), sizeIfKnown), > flags); > > You might want ORDERED as a flag. > > > On 12/11/2012 1:07 AM, Fran?ois Sarradin wrote: > >> Hi, >> >> Is there a way to get a Stream from an Iterable with the update b67? >> >> Should I create a Collection first or is there something shorter? >> >> Regards, >> Fran?ois Sarradin >> >> From dmitry.bessonov at oracle.com Tue Dec 11 13:00:11 2012 From: dmitry.bessonov at oracle.com (Dmitry Bessonov) Date: Wed, 12 Dec 2012 01:00:11 +0400 Subject: A no-arg sibling of java.util.function.Block ? Message-ID: <50C79EDB.8060909@oracle.com> Hello, I cannot find a standard interface that will allow me to basically wrap a delayed operation that requires no input objects. In other words is there a j.u.f.Block but without necessity to supply input object? (Sorry if such standard interface exists already) -Dmitry From spullara at gmail.com Tue Dec 11 13:09:22 2012 From: spullara at gmail.com (Sam Pullara) Date: Tue, 11 Dec 2012 13:09:22 -0800 Subject: A no-arg sibling of java.util.function.Block ? In-Reply-To: <50C79EDB.8060909@oracle.com> References: <50C79EDB.8060909@oracle.com> Message-ID: Runnable should work for that, no? Sam On Dec 11, 2012, at 1:00 PM, Dmitry Bessonov wrote: > Hello, > > I cannot find a standard interface that will allow me to basically wrap > a delayed operation that requires no input objects. > > In other words is there a j.u.f.Block but without necessity to supply > input object? > > (Sorry if such standard interface exists already) > > -Dmitry > From dmitry.bessonov at oracle.com Tue Dec 11 13:24:54 2012 From: dmitry.bessonov at oracle.com (Dmitry Bessonov) Date: Wed, 12 Dec 2012 01:24:54 +0400 Subject: A no-arg sibling of java.util.function.Block ? In-Reply-To: References: <50C79EDB.8060909@oracle.com> Message-ID: <50C7A4A6.5030807@oracle.com> On 12.12.2012 1:09, Sam Pullara wrote: > Runnable should work for that, no? Technically - yes. But (... after reading spec for Runnable) - would that be a good use of Runnable interface from ideological point of view? -Dmitry > > Sam > > On Dec 11, 2012, at 1:00 PM, Dmitry Bessonov wrote: > >> Hello, >> >> I cannot find a standard interface that will allow me to basically wrap >> a delayed operation that requires no input objects. >> >> In other words is there a j.u.f.Block but without necessity to supply >> input object? >> >> (Sorry if such standard interface exists already) >> >> -Dmitry >> > From spullara at gmail.com Tue Dec 11 13:28:08 2012 From: spullara at gmail.com (Sam Pullara) Date: Tue, 11 Dec 2012 13:28:08 -0800 Subject: A no-arg sibling of java.util.function.Block ? In-Reply-To: <50C7A4A6.5030807@oracle.com> References: <50C79EDB.8060909@oracle.com> <50C7A4A6.5030807@oracle.com> Message-ID: <78BFE70B-C269-4DDA-8895-231AFE14CAC8@sampullara> I always thought of Block as Runnable with an argument and have used Runnable for tasks like this in JDK 6. YMMV. "The Runnable interface should be implemented by any class whose instances are intended to be executed by a thread." It will actually be executed by a thread and in a parallel case it may even be a different thread. I'm ok ideologically with using it. Sam On Dec 11, 2012, at 1:24 PM, Dmitry Bessonov wrote: > On 12.12.2012 1:09, Sam Pullara wrote: >> Runnable should work for that, no? > Technically - yes. > But (... after reading spec for Runnable) - would that be a good use of Runnable interface from ideological point of view? > > -Dmitry > >> >> Sam >> >> On Dec 11, 2012, at 1:00 PM, Dmitry Bessonov wrote: >> >>> Hello, >>> >>> I cannot find a standard interface that will allow me to basically wrap >>> a delayed operation that requires no input objects. >>> >>> In other words is there a j.u.f.Block but without necessity to supply >>> input object? >>> >>> (Sorry if such standard interface exists already) >>> >>> -Dmitry >>> >> > From dmitry.bessonov at oracle.com Tue Dec 11 13:36:12 2012 From: dmitry.bessonov at oracle.com (Dmitry Bessonov) Date: Wed, 12 Dec 2012 01:36:12 +0400 Subject: A no-arg sibling of java.util.function.Block ? In-Reply-To: <78BFE70B-C269-4DDA-8895-231AFE14CAC8@sampullara> References: <50C79EDB.8060909@oracle.com> <50C7A4A6.5030807@oracle.com> <78BFE70B-C269-4DDA-8895-231AFE14CAC8@sampullara> Message-ID: <50C7A74C.7090603@oracle.com> A limitation to mention - Runnables can not be easily chained while Blocks can be... -Dmitry On 12.12.2012 1:28, Sam Pullara wrote: > I always thought of Block as Runnable with an argument and have used Runnable for tasks like this in JDK 6. YMMV. > > "The Runnable interface should be implemented by any class whose instances are intended to be executed by a thread." > > It will actually be executed by a thread and in a parallel case it may even be a different thread. I'm ok ideologically with using it. > > Sam > > On Dec 11, 2012, at 1:24 PM, Dmitry Bessonov wrote: > >> On 12.12.2012 1:09, Sam Pullara wrote: >>> Runnable should work for that, no? >> Technically - yes. >> But (... after reading spec for Runnable) - would that be a good use of Runnable interface from ideological point of view? >> >> -Dmitry >> >>> Sam >>> >>> On Dec 11, 2012, at 1:00 PM, Dmitry Bessonov wrote: >>> >>>> Hello, >>>> >>>> I cannot find a standard interface that will allow me to basically wrap >>>> a delayed operation that requires no input objects. >>>> >>>> In other words is there a j.u.f.Block but without necessity to supply >>>> input object? >>>> >>>> (Sorry if such standard interface exists already) >>>> >>>> -Dmitry >>>> From spullara at gmail.com Tue Dec 11 13:37:01 2012 From: spullara at gmail.com (Sam Pullara) Date: Tue, 11 Dec 2012 13:37:01 -0800 Subject: A no-arg sibling of java.util.function.Block ? In-Reply-To: <50C7A74C.7090603@oracle.com> References: <50C79EDB.8060909@oracle.com> <50C7A4A6.5030807@oracle.com> <78BFE70B-C269-4DDA-8895-231AFE14CAC8@sampullara> <50C7A74C.7090603@oracle.com> Message-ID: <0818259B-C3DE-4CF1-B754-B89692CF2BFD@sampullara> We could add the same default method to Runnable in JDK8 to fix that. Sam On Dec 11, 2012, at 1:36 PM, Dmitry Bessonov wrote: > A limitation to mention - Runnables can not be easily chained while Blocks can be... > > -Dmitry > > On 12.12.2012 1:28, Sam Pullara wrote: >> I always thought of Block as Runnable with an argument and have used Runnable for tasks like this in JDK 6. YMMV. >> >> "The Runnable interface should be implemented by any class whose instances are intended to be executed by a thread." >> >> It will actually be executed by a thread and in a parallel case it may even be a different thread. I'm ok ideologically with using it. >> >> Sam >> >> On Dec 11, 2012, at 1:24 PM, Dmitry Bessonov wrote: >> >>> On 12.12.2012 1:09, Sam Pullara wrote: >>>> Runnable should work for that, no? >>> Technically - yes. >>> But (... after reading spec for Runnable) - would that be a good use of Runnable interface from ideological point of view? >>> >>> -Dmitry >>> >>>> Sam >>>> >>>> On Dec 11, 2012, at 1:00 PM, Dmitry Bessonov wrote: >>>> >>>>> Hello, >>>>> >>>>> I cannot find a standard interface that will allow me to basically wrap >>>>> a delayed operation that requires no input objects. >>>>> >>>>> In other words is there a j.u.f.Block but without necessity to supply >>>>> input object? >>>>> >>>>> (Sorry if such standard interface exists already) >>>>> >>>>> -Dmitry >>>>> > From mike.duigou at oracle.com Tue Dec 11 16:56:26 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 11 Dec 2012 16:56:26 -0800 Subject: OpenJDK Java 8 with Lambda Preview b68 Promoted Message-ID: <3EAF1E71-7820-43A6-B90D-528CCD192226@oracle.com> Hello Lambdacizers; A new promotion (b68) of preview binaries for OpenJDK Java 8 with lambda extensions is now available at http://jdk8.java.net/lambda/ This release is synced with jdk8 b66 and some jdk8 b67 changesets. This build greatly reduces the difference between the OpenJDK 8 mainline (http://hg.openjdk.java.net/jdk8/jdk8) and the lambda repo (http://hg.openjdk.java.net/lambda/lambda) for both HotSpot and the javac compiler. On the libraries side work continues to advance quickly with many additional refinements to parallel streams. As well, some of our "lambdafication" efforts to Collections, ThreadLocal, BufferedReader are starting to hit the repo. These will migrate to the mainline repo as we complete reviews and testing. We will start to see the size of the library differences between mainline and lambda shrink beginning with the next promotion. Enjoy and, as always, feedback is welcome and appreciated. From brian.goetz at oracle.com Tue Dec 11 16:58:52 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 11 Dec 2012 19:58:52 -0500 Subject: StreamOpFlag.* and OutOfMemoryError when going parall In-Reply-To: References: <50BF93A7.8000400@oracle.com> Message-ID: <50C7D6CC.7030406@oracle.com> I've fixed the bug in parallel limit. Give it a try (you'll have to rebuild from source.) On 12/5/2012 1:54 PM, Christian Mallwitz wrote: > Very well :-) > > Leaving the parallel aspect aside, If I just wanted to find the first > n prime numbers based on a possibly infinity stream of numbers (I > don't want to use a Collection with a known size), is there another > 'officially' approved way to covert an Iterator to a Stream (instead > of using Streams.stream())? > > Regarding a fully lazy, parallel limit() and its future: does 'future' > mean pre- or post-JDK8? > > Cheers! > Christian > > On Wed, Dec 5, 2012 at 6:34 PM, Brian Goetz wrote: >> There's a good reason you are struggling with it -- this API is not intended >> for "casual" builders of streams. The intention is that 99.9% of users will >> never write code to call the Streams.stream() method directly; they will use >> arrays, collections, generators, or other packaged providers of streams. >> >> A safe default is 0. You can OR together the IS_ version of the flags if >> you know something about the nature of your stream. You probably want >> IS_ORDERED if you want to represent a stream for which the order of elements >> means something (e.g., a range generator, a List, an array, etc.) >> >> The reason it is failing with OOME is that the parallel implementation of >> limit() computes the entire results rather than operating fully lazily. >> While it would be preferable to operate more lazily, a lazy parallel >> implementation of operations like limit is not trivial. We hope to improve >> this in the future. >> >> On 12/5/2012 1:18 PM, Christian Mallwitz wrote: >>> >>> Hi, >>> >>> Using lambda-8-b67-linux-i586-03_dec_2012 I'm trying to compute n (not >>> necessarily the first n) prime numbers: >>> >>> import java.util.*; >>> import java.util.function.*; >>> import java.util.stream.*; >>> >>> public class LambdaExample3 { >>> >>> public static boolean isPrime(long n) { >>> if (n <= 1) { return false; } >>> if (n == 2) { return true; } >>> for (int i = 2; i <= Math.sqrt(n) + 1; i++) { if (n % i == 0) >>> return false; } >>> return true; >>> } >>> >>> public static void main(String[] args) { >>> >>> Stream stream = >>> Streams.parallel(Streams.spliteratorUnknownSize(new Iterator() { >>> private long n = 0; >>> @Override public boolean hasNext() { return true; } >>> @Override public Long next() { return ++n; } >>> }), >>> // fails with OutOfMemoryError >>> // StreamOpFlag.toStreamFlags(StreamOpFlag.NOT_SIZED, >>> StreamOpFlag.INITIAL_OPS_VALUE) >>> // fails with OutOfMemoryError >>> // StreamOpFlag.NOT_SIZED >>> // works, but no speed-up to non-parallel version >>> StreamOpFlag.INITIAL_OPS_VALUE >>> ); >>> >>> stream >>> .filter(LambdaExample3::isPrime) >>> .limit(300000) >>> .forEach(l -> { /*System.out.println(l);*/ }); >>> } >>> } >>> >>> I'm struggling with the StreamOpFlag parameter. What should I pick? >>> INITIAL_OPS_VALUE seems to work but isn't running anything in parallel >>> (at least it is not faster than the serial version). NOT_SIZED isn't >>> working but failing miserably with an OutOfMemoryError. IS_PARALLEL >>> is not needed because I already use parallel() - should specifying >>> IS_PARALLEL and using Streams.stream() supposed to go parallel as >>> well? >>> >>> Is the OutOfMemoryError caused by a bug? The OutOfMemoryError is >>> reported from a fork/join pool thread so at least it is going >>> parallel? Am I missing something? >>> >>> Thanks >>> Christian >>> >> > From brian.goetz at oracle.com Tue Dec 11 16:58:21 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 12 Dec 2012 00:58:21 +0000 Subject: hg: lambda/lambda/jdk: Fix bug in parallel limit on infinite streams Message-ID: <20121212005846.4BE824709D@hg.openjdk.java.net> Changeset: 88069b7fbdf7 Author: briangoetz Date: 2012-12-11 19:57 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/88069b7fbdf7 Fix bug in parallel limit on infinite streams ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/stream/op/SliceOp.java ! test-ng/tests/org/openjdk/tests/java/util/stream/ParallelRangeTest.java From aruld at acm.org Tue Dec 11 17:46:54 2012 From: aruld at acm.org (Arul Dhesiaseelan) Date: Tue, 11 Dec 2012 15:46:54 -1000 Subject: sum of numbers using Primitives range Message-ID: Sum of integers over using a Primitives range returns invalid result. range(1, 10).map(operand -> operand).sum(); range(1, 10).reduce(0, Integer::sum); range(1, 10).sum(); They all yield 45, instead of 55. Is this a bug? -Arul From misterm at gmail.com Tue Dec 11 17:55:15 2012 From: misterm at gmail.com (Michael Nascimento) Date: Tue, 11 Dec 2012 23:55:15 -0200 Subject: sum of numbers using Primitives range In-Reply-To: References: Message-ID: There is no Javadoc, so it's hard to say, but isn't it because the range is supposed to be open in the end? Regards, Michael On Tue, Dec 11, 2012 at 11:46 PM, Arul Dhesiaseelan wrote: > Sum of integers over using a Primitives range returns invalid result. > > range(1, 10).map(operand -> operand).sum(); > range(1, 10).reduce(0, Integer::sum); > range(1, 10).sum(); > > > They all yield 45, instead of 55. Is this a bug? > > -Arul > From brian.goetz at oracle.com Tue Dec 11 17:55:24 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 11 Dec 2012 20:55:24 -0500 Subject: sum of numbers using Primitives range In-Reply-To: References: Message-ID: <50C7E40C.8090202@oracle.com> 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 = 45. Ranges are half-open. As in, for (int i=0; i<10; i++) { ... } On 12/11/2012 8:46 PM, Arul Dhesiaseelan wrote: > Sum of integers over using a Primitives range returns invalid result. > > range(1, 10).map(operand -> operand).sum(); > range(1, 10).reduce(0, Integer::sum); > range(1, 10).sum(); > > > They all yield 45, instead of 55. Is this a bug? > > -Arul > From aruld at acm.org Tue Dec 11 18:10:22 2012 From: aruld at acm.org (Arul Dhesiaseelan) Date: Tue, 11 Dec 2012 16:10:22 -1000 Subject: sum of numbers using Primitives range In-Reply-To: <50C7E40C.8090202@oracle.com> References: <50C7E40C.8090202@oracle.com> Message-ID: My bad, I was assuming inclusive. Thanks Brian. On Tue, Dec 11, 2012 at 3:55 PM, Brian Goetz wrote: > 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 = 45. Ranges are half-open. As in, > > for (int i=0; i<10; i++) { ... } > > > > > On 12/11/2012 8:46 PM, Arul Dhesiaseelan wrote: > >> Sum of integers over using a Primitives range returns invalid result. >> >> range(1, 10).map(operand -> operand).sum(); >> range(1, 10).reduce(0, Integer::sum); >> range(1, 10).sum(); >> >> >> They all yield 45, instead of 55. Is this a bug? >> >> -Arul >> >> From mike.duigou at oracle.com Tue Dec 11 18:15:54 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 12 Dec 2012 02:15:54 +0000 Subject: hg: lambda/lambda/corba: 2 new changesets Message-ID: <20121212021559.8B0C7470A0@hg.openjdk.java.net> Changeset: 82000531feaa Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/82000531feaa Added tag jdk8-b67 for changeset 394515ad2a55 ! .hgtags Changeset: 6e1f58f648f7 Author: mduigou Date: 2012-12-11 17:15 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/corba/rev/6e1f58f648f7 Merge ! .hgtags From mike.duigou at oracle.com Tue Dec 11 18:16:00 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 12 Dec 2012 02:16:00 +0000 Subject: hg: lambda/lambda/jaxws: 2 new changesets Message-ID: <20121212021607.CBE10470A1@hg.openjdk.java.net> Changeset: d3fe408f3a9a Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/d3fe408f3a9a Added tag jdk8-b67 for changeset eb06aa51dfc2 ! .hgtags Changeset: d42c09d6b6de Author: mduigou Date: 2012-12-11 17:16 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxws/rev/d42c09d6b6de Merge ! .hgtags From mike.duigou at oracle.com Tue Dec 11 18:16:00 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 12 Dec 2012 02:16:00 +0000 Subject: hg: lambda/lambda/jaxp: 2 new changesets Message-ID: <20121212021612.5A07A470A2@hg.openjdk.java.net> Changeset: b854e7008421 Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/b854e7008421 Added tag jdk8-b67 for changeset 83df3493ca3c ! .hgtags Changeset: d1bf381bd0d8 Author: mduigou Date: 2012-12-11 17:15 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jaxp/rev/d1bf381bd0d8 Merge ! .hgtags From mike.duigou at oracle.com Tue Dec 11 18:15:59 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 12 Dec 2012 02:15:59 +0000 Subject: hg: lambda/lambda/hotspot: 27 new changesets Message-ID: <20121212021702.BC7C5470A3@hg.openjdk.java.net> Changeset: e1d42ba865de Author: amurillo Date: 2012-11-16 09:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/e1d42ba865de 8003541: new hotspot build - hs25-b11 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 49cbd3e25ba9 Author: zgu Date: 2012-11-16 09:05 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/49cbd3e25ba9 8003487: NMT: incorrect assertion in VMMemPointerIterator::remove_released_region method (memSnapshot.cpp) Summary: The assertion is applied to only the region to be released, also performs region integrity checking Reviewed-by: acorn, coleenp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp Changeset: 3ed6de6e139b Author: coleenp Date: 2012-11-20 20:27 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/3ed6de6e139b Merge Changeset: 73e64867adb7 Author: mikael Date: 2012-11-21 09:02 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/73e64867adb7 8003690: Example code in JVMTI GetStackTrace documentation is broken Summary: Fixed to minor errors in example code Reviewed-by: sspitsyn, dholmes ! src/share/vm/prims/jvmti.xml Changeset: 6b881a6b0665 Author: dholmes Date: 2012-11-21 20:07 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/6b881a6b0665 8003591: Abstract_VM_Version::internal_vm_info_string needs to stringify FLOAT_ARCH for ease of use Reviewed-by: coleenp, kvn ! src/share/vm/runtime/vm_version.cpp Changeset: ca1be5fbe6ff Author: dholmes Date: 2012-11-21 21:26 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/ca1be5fbe6ff Merge Changeset: 7c15faa95ce7 Author: mikael Date: 2012-11-27 07:57 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/7c15faa95ce7 8003879: Duplicate definitions in vmStructs Summary: Removed duplicate entries Reviewed-by: dholmes, sspitsyn ! src/share/vm/gc_implementation/concurrentMarkSweep/vmStructs_cms.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmStructs.hpp Changeset: bbc14465e7db Author: zgu Date: 2012-11-28 09:19 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/bbc14465e7db 8003689: MemTracker::init_tracking_options() reads outside array if commandline argument is empty Summary: Fixed potential buffer overrun when giving empty option to NativeMemoryTracking commandline option Reviewed-by: ctornqvi, hseigel, kvn ! src/share/vm/services/memTracker.cpp Changeset: 5de2a5bd519e Author: zgu Date: 2012-11-28 06:42 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5de2a5bd519e Merge Changeset: fe81517cfb77 Author: hseigel Date: 2012-11-28 08:17 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/fe81517cfb77 6924920: Class Data Sharing limit on the java version string can create failures Summary: Truncate the java version string and add a hash value if it is too long. Reviewed-by: dholmes, coleenp ! src/share/vm/memory/filemap.cpp Changeset: b51dc8df86e5 Author: coleenp Date: 2012-11-28 08:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b51dc8df86e5 Merge Changeset: 59c790074993 Author: coleenp Date: 2012-11-28 17:50 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/59c790074993 8003635: NPG: AsynchGetCallTrace broken by Method* virtual call Summary: Make metaspace::contains be lock free and used to see if something is in metaspace, also compare Method* with vtbl pointer. Reviewed-by: dholmes, sspitsyn, dcubed, jmasa ! src/cpu/sparc/vm/frame_sparc.cpp ! src/cpu/x86/vm/frame_x86.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/allocation.cpp ! src/share/vm/memory/allocation.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/compiledICHolder.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 53715fb1597d Author: brutisso Date: 2012-11-20 11:40 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/53715fb1597d 7198334: UseNUMA modifies system parameters on non-NUMA system Summary: The flags MinHeapDeltaBytes and UseNUMAInterleaving must be adjusted after the OS have adjusted the UseNUMA flag in the method os::init_2. Reviewed-by: dholmes, brutisso Contributed-by: erik.helin at oracle.com ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/thread.cpp Changeset: 19c1bd641922 Author: coleenp Date: 2012-11-26 12:31 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/19c1bd641922 8003722: More gcc 4.7 compilation errors Summary: Add a few more this->qualifications. Reviewed-by: coleenp, dholmes Contributed-by: duboscq at ssw.jku.at ! src/share/vm/memory/binaryTreeDictionary.cpp Changeset: d0aa87f04bd5 Author: stefank Date: 2012-11-27 10:13 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/d0aa87f04bd5 8003720: NPG: Method in interpreter stack frame can be deallocated Summary: Pass down a closure during root scanning to keep the class of the method alive. Reviewed-by: coleenp, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psTasks.cpp ! src/share/vm/memory/iterator.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp + test/runtime/8003720/Asmator.java + test/runtime/8003720/Test8003720.java + test/runtime/8003720/Victim.java + test/runtime/8003720/VictimClassLoader.java Changeset: f34d701e952e Author: stefank Date: 2012-11-27 14:20 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/f34d701e952e 8003935: Simplify the needed includes for using Thread::current() Reviewed-by: dholmes, rbackman, coleenp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/stubRoutines_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_32.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/zero/vm/interp_masm_zero.cpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/cpu/zero/vm/stubRoutines_zero.cpp ! src/os/bsd/vm/mutex_bsd.cpp ! src/os/bsd/vm/mutex_bsd.inline.hpp ! src/os/bsd/vm/os_bsd.cpp ! src/os/bsd/vm/threadCritical_bsd.cpp ! src/os/bsd/vm/thread_bsd.inline.hpp ! src/os/linux/vm/mutex_linux.cpp ! src/os/linux/vm/mutex_linux.inline.hpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/threadCritical_linux.cpp ! src/os/linux/vm/thread_linux.inline.hpp ! src/os/solaris/vm/mutex_solaris.cpp ! src/os/solaris/vm/mutex_solaris.inline.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/threadCritical_solaris.cpp ! src/os/solaris/vm/thread_solaris.inline.hpp ! src/os/windows/vm/mutex_windows.cpp ! src/os/windows/vm/mutex_windows.inline.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/threadCritical_windows.cpp ! src/os/windows/vm/thread_windows.inline.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/threadLS_bsd_x86.cpp ! src/os_cpu/bsd_x86/vm/thread_bsd_x86.cpp ! src/os_cpu/bsd_zero/vm/os_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/threadLS_bsd_zero.cpp ! src/os_cpu/bsd_zero/vm/thread_bsd_zero.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/threadLS_linux_sparc.cpp ! src/os_cpu/linux_sparc/vm/thread_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_x86/vm/threadLS_linux_x86.cpp ! src/os_cpu/linux_x86/vm/thread_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/linux_zero/vm/threadLS_linux_zero.cpp ! src/os_cpu/linux_zero/vm/thread_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/threadLS_solaris_sparc.cpp ! src/os_cpu/solaris_sparc/vm/thread_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/threadLS_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/thread_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/os_windows_x86.cpp ! src/os_cpu/windows_x86/vm/threadLS_windows_x86.cpp ! src/os_cpu/windows_x86/vm/thread_windows_x86.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepThread.hpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/g1SATBCardTableModRefBS.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/freeBlockDictionary.cpp ! src/share/vm/memory/gcLocker.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/resourceArea.cpp ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/markOop.cpp ! src/share/vm/oops/oop.cpp ! src/share/vm/oops/oopsHierarchy.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/handles.cpp ! src/share/vm/runtime/handles.inline.hpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/jniHandles.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/task.cpp ! src/share/vm/runtime/thread.cpp + src/share/vm/runtime/thread.inline.hpp ! src/share/vm/runtime/threadLocalStorage.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmThread.cpp ! src/share/vm/runtime/vmThread.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/services/memTracker.hpp ! src/share/vm/utilities/array.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/events.cpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/growableArray.cpp ! src/share/vm/utilities/preserveException.hpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/workgroup.hpp Changeset: 2fc0334f613a Author: johnc Date: 2012-11-27 14:11 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/2fc0334f613a 7194633: G1: Assertion and guarantee failures in block offset table Summary: Add detailed error messages to assertions and guarantees in G1's block offset table. Reviewed-by: ysr, brutisso ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.inline.hpp ! src/share/vm/memory/space.cpp Changeset: c24f778e9401 Author: johnc Date: 2012-11-29 11:23 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/c24f778e9401 Merge ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: b2dbd323c668 Author: jiangli Date: 2012-11-27 17:03 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b2dbd323c668 8003848: Make ConstMethod::generic_signature_index optional and move Method::_max_stack to ConstMethod. Summary: Make ConstMethod::generic_signature_index optional and move Method::_max_stack to ConstMethod. Reviewed-by: bdelsart, sspitsyn, coleenp ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5505fbbae3d3 Author: cjplummer Date: 2012-11-29 13:55 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5505fbbae3d3 Merge ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 90273fc0a981 Author: coleenp Date: 2012-11-29 16:50 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/90273fc0a981 8000662: NPG: nashorn ant clean test262 out-of-memory with Java heap Summary: Add ClassLoaderData object for each anonymous class with metaspaces to allocate in. Reviewed-by: twisti, jrose, stefank ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/ci/ciReplay.hpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/classfile/classLoaderData.inline.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/prims/unsafe.cpp Changeset: dad48145e775 Author: stefank Date: 2012-11-29 23:02 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/dad48145e775 8004199: Change the ASM package for Test8003720 Reviewed-by: kvn, jrose ! test/runtime/8003720/Asmator.java ! test/runtime/8003720/Test8003720.java Changeset: 5fafdef522c6 Author: johnc Date: 2012-11-30 12:01 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/5fafdef522c6 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/memory/universe.cpp Changeset: b61d9c88b759 Author: amurillo Date: 2012-11-30 16:45 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b61d9c88b759 Merge Changeset: 25bdce771bb3 Author: amurillo Date: 2012-11-30 16:45 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/25bdce771bb3 Added tag hs25-b11 for changeset b61d9c88b759 ! .hgtags Changeset: 10587a580c51 Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/10587a580c51 Added tag jdk8-b67 for changeset 25bdce771bb3 ! .hgtags Changeset: 940c7ddb1e50 Author: mduigou Date: 2012-12-11 17:20 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/940c7ddb1e50 Merge ! .hgtags ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp From mike.duigou at oracle.com Tue Dec 11 18:25:52 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 11 Dec 2012 18:25:52 -0800 Subject: lambda repos synced to jdk8 master Message-ID: <798ECECB-D4B7-430D-BE52-C33A7FFDE6E6@oracle.com> Another lambda promotion means another sync to the mainline master (http://hg.openjdk.java.net/jdk8/jdk8). All but the the langtools repo are now synced against the master. Langtools will probably be merged in a day or two at most. I verified the merge with a comprehensive jtreg run. Mike From mike.duigou at oracle.com Tue Dec 11 18:16:14 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 12 Dec 2012 02:16:14 +0000 Subject: hg: lambda/lambda/jdk: 70 new changesets Message-ID: <20121212023123.DD916470A6@hg.openjdk.java.net> Changeset: b0f008ab45d7 Author: twisti Date: 2012-11-30 11:42 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b0f008ab45d7 8001885: JSR 292 classes should use jdk.internal.org.objectweb.asm Reviewed-by: kvn, jrose, twisti Contributed-by: David Chase ! src/share/classes/java/lang/invoke/BoundMethodHandle.java ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java Changeset: 0fda013e4638 Author: erikj Date: 2012-12-05 10:12 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0fda013e4638 8004281: build-infra: Move all jar creation to images target and put jars in images/lib Reviewed-by: ohair, tbell, dholmes ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk ! makefiles/Import.gmk Changeset: ce9b02a3a17e Author: katleman Date: 2012-12-05 12:53 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ce9b02a3a17e Merge Changeset: ea0d3a9d0d01 Author: katleman Date: 2012-12-06 12:04 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ea0d3a9d0d01 Added tag jdk8-b67 for changeset ce9b02a3a17e ! .hgtags Changeset: 39f9b2cc5738 Author: bae Date: 2012-11-28 12:28 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/39f9b2cc5738 4649812: GIFImageReader handles transparency incorrectly Reviewed-by: bae, prr Contributed-by: Vadim Pakhnushev ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReader.java Changeset: 6569819eb2fe Author: bae Date: 2012-11-28 12:38 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6569819eb2fe 5082749: GIF stream metadata specification of aspect ratio is incorrect Reviewed-by: bae, prr Contributed-by: Vadim Pakhnushev ! src/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html Changeset: 934595726263 Author: bae Date: 2012-11-28 14:12 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/934595726263 7064516: ImageIO.read() fails to load an image Reviewed-by: jgodinez, prr ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/awt/image/ColorConvertOp.java + test/sun/java2d/cmm/ColorConvertOp/InvalidRenderIntentTest.java Changeset: d54db1e16b97 Author: bae Date: 2012-11-30 11:32 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d54db1e16b97 7124223: [macosx] Regression test failure with new exception, when glyph is positioned explicitly Reviewed-by: jgodinez ! src/share/classes/sun/print/PathGraphics.java Changeset: bd3b3cda125d Author: lana Date: 2012-11-30 16:02 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bd3b3cda125d Merge Changeset: 3c5bf5ed45a9 Author: bae Date: 2012-12-03 16:26 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3c5bf5ed45a9 7124347: [macosx] java.lang.InternalError: not implemented yet on call Graphics2D.drawRenderedImage Reviewed-by: prr, flar ! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java ! src/share/classes/sun/java2d/opengl/OGLSurfaceDataProxy.java + test/sun/java2d/OpenGL/CustomCompositeTest.java Changeset: 1175410d98ea Author: serb Date: 2012-11-21 15:50 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1175410d98ea 7124552: [macosx] NullPointerException in getBufferStrategy() 7124219: [macosx] Unable to draw images to fullscreen Reviewed-by: bae, anthony ! src/macosx/classes/sun/awt/CGraphicsConfig.java ! src/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java ! src/macosx/classes/sun/lwawt/LWCanvasPeer.java ! src/macosx/classes/sun/lwawt/LWComponentPeer.java + src/macosx/classes/sun/lwawt/LWGraphicsConfig.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: 5b2c31d20a64 Author: serb Date: 2012-11-21 15:54 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5b2c31d20a64 7193214: Consider simplifying CPlatformWindow.setResizable() Reviewed-by: anthony, denis ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: c9dead63607c Author: serb Date: 2012-11-21 15:58 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c9dead63607c 7154516: [macosx] Popup menus have no visible borders Reviewed-by: anthony, denis ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java Changeset: 9cd48409539e Author: kizune Date: 2012-11-21 20:42 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9cd48409539e 8003273: Missing testcase for 7171812 Reviewed-by: art, serb + test/javax/swing/dnd/7171812/JListWithScroll.java + test/javax/swing/dnd/7171812/bug7171812.java Changeset: 5600005b87fb Author: serb Date: 2012-11-27 17:03 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5600005b87fb 8002308: [macosx] 7198229 should be applied to the user action only Reviewed-by: anthony, skovatch ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m + test/java/awt/Frame/FrameSetSizeStressTest/FrameSetSizeStressTest.java Changeset: 0e91d6f3019c Author: alexsch Date: 2012-11-29 07:42 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0e91d6f3019c 8000423: Diacritic is not applyed to a base letter on Linux Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: abee1d528df1 Author: kshefov Date: 2012-11-30 12:39 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/abee1d528df1 7124242: [macosx] Test doesn't work because of the frame round corners in the LaF Reviewed-by: anthony, yan, alexsch ! test/javax/swing/text/CSSBorder/6796710/bug6796710.java Changeset: 35d8085aa14a Author: lana Date: 2012-11-30 17:09 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/35d8085aa14a Merge Changeset: da55ef766e48 Author: alexsch Date: 2012-12-04 15:26 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/da55ef766e48 6671481: NPE at javax.swing.plaf.basic.BasicTreeUI$Handler.handleSelection Reviewed-by: serb ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java Changeset: bd175c70684c Author: alexsch Date: 2012-12-04 15:56 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bd175c70684c 8003830: NPE at BasicTreeUI$Actions.page:4470 Reviewed-by: serb, alexsch Contributed-by: Jaroslav Tulach ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/8003830/bug8003830.java Changeset: 009fd6e1d9f5 Author: alexsch Date: 2012-12-04 16:42 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/009fd6e1d9f5 8002077: Possible mnemonic issue on JFileChooser Save button on nimbus L&F Reviewed-by: serb ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUI.java Changeset: 4aad3e6f68d2 Author: jviswana Date: 2012-12-04 17:17 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4aad3e6f68d2 4631925: JColor Chooser is not fully accessible Reviewed-by: alexsch ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorPanel.java ! src/share/classes/javax/swing/plaf/basic/BasicColorChooserUI.java Changeset: ea20c9388d90 Author: aph Date: 2012-12-04 14:02 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ea20c9388d90 8004344: Fix a crash in ToolkitErrorHandler() in XlibWrapper.c Summary: Code does not check for JNU_GetEnv returning NULL. Reviewed-by: anthony ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: bbbb5c70aa59 Author: lana Date: 2012-12-04 11:41 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bbbb5c70aa59 Merge - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: f389bf27fc4f Author: dbuck Date: 2012-11-20 21:35 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f389bf27fc4f 7198904: (alt-rt) TreeMap.clone is broken Summary: Test case for cr7198904. Issue only found in OracleJDK, but test case is valid for OpenJDK as well Reviewed-by: mduigou, dholmes + test/java/util/TreeMap/Clone.java Changeset: ee6e5b7d5d55 Author: uta Date: 2012-11-23 13:07 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ee6e5b7d5d55 8003898: X11 toolkit can be chosen as the default toolkit Summary: XToolkit is not selected for any values of system-wide environment variables (ex. DISPLAY). Reviewed-by: anthony, art ! src/solaris/native/java/lang/java_props_macosx.c Changeset: 621c379d909d Author: xuelei Date: 2012-11-24 03:34 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/621c379d909d 8001751: Javadoc warnings in JSSE code Reviewed-by: alanb ! src/share/classes/javax/net/ssl/HostnameVerifier.java ! src/share/classes/javax/net/ssl/SNIHostName.java ! src/share/classes/javax/net/ssl/SNIMatcher.java ! src/share/classes/javax/net/ssl/SNIServerName.java ! src/share/classes/javax/net/ssl/SSLParameters.java ! src/share/classes/javax/net/ssl/SSLSocketFactory.java Changeset: f7d45462b225 Author: xuelei Date: 2012-11-24 04:09 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f7d45462b225 8003950: Adds missing Override annotations and removes unnecessary imports in sun.security.ssl Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/AppInputStream.java ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/BaseSSLSocketImpl.java ! src/share/classes/sun/security/ssl/ByteBufferInputStream.java ! src/share/classes/sun/security/ssl/CipherBox.java ! 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/DHClientKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHClientKeyExchange.java ! src/share/classes/sun/security/ssl/ECDHCrypt.java ! src/share/classes/sun/security/ssl/EngineInputRecord.java ! src/share/classes/sun/security/ssl/EngineOutputRecord.java ! src/share/classes/sun/security/ssl/EngineWriter.java ! src/share/classes/sun/security/ssl/ExtensionType.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/HandshakeInStream.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/HandshakeOutStream.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtension.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/InputRecord.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/Krb5Helper.java ! src/share/classes/sun/security/ssl/OutputRecord.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/ProtocolVersion.java ! src/share/classes/sun/security/ssl/RSAClientKeyExchange.java ! src/share/classes/sun/security/ssl/RSASignature.java ! src/share/classes/sun/security/ssl/RenegotiationInfoExtension.java ! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/SSLEngineImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/SSLSocketImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/ServerNameExtension.java ! src/share/classes/sun/security/ssl/SessionId.java ! src/share/classes/sun/security/ssl/SunJSSE.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/SupportedEllipticCurvesExtension.java ! src/share/classes/sun/security/ssl/SupportedEllipticPointFormatsExtension.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/UnknownExtension.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java Changeset: d30c13172254 Author: xuelei Date: 2012-11-24 04:27 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d30c13172254 8003951: Removes unused variables in sun.security.ssl Reviewed-by: xuelei Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/JsseJce.java ! src/share/classes/sun/security/ssl/SSLServerSocketImpl.java ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/ssl/SSLSocketFactoryImpl.java ! src/share/classes/sun/security/ssl/X509TrustManagerImpl.java Changeset: 8970128e040d Author: uta Date: 2012-11-26 15:54 +0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8970128e040d 7162111: TEST_BUG: change tests run in headless mode [macosx] (open) Summary: In problem tests detection of AWT headless mode was introduced or AWT dependence was removed. Reviewed-by: alanb ! test/ProblemList.txt ! test/demo/jvmti/mtrace/TraceJFrame.java ! test/java/io/Serializable/resolveClass/deserializeButton/Foo.java ! test/java/io/Serializable/resolveClass/deserializeButton/Test.java ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh Changeset: 054470092795 Author: mullan Date: 2012-11-26 08:12 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/054470092795 7167056: Clarify that BasicPermission names that contain non-wildcard asterisks are not invalid Reviewed-by: weijun, xuelei ! src/share/classes/com/sun/net/ssl/SSLPermission.java ! src/share/classes/java/lang/RuntimePermission.java ! src/share/classes/java/net/NetPermission.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/javax/net/ssl/SSLPermission.java + test/java/security/BasicPermission/Wildcard.java Changeset: ea66140be78d Author: mullan Date: 2012-11-26 08:23 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ea66140be78d Merge - makefiles/docs/CORE_PKGS.gmk - makefiles/docs/Makefile - makefiles/docs/NON_CORE_PKGS.gmk - makefiles/docs/Notes.html - makefiles/mapfiles/launchers/mapfile-amd64 - makefiles/mapfiles/launchers/mapfile-i586 - makefiles/mapfiles/libawt_headless/reorder-i586 - makefiles/mapfiles/libjava/reorder-i586 - makefiles/mapfiles/libjpeg/reorder-i586 - makefiles/mapfiles/libnio/mapfile-bsd - makefiles/mapfiles/libnio/reorder-i586 - makefiles/mapfiles/libverify/reorder-i586 - makefiles/mapfiles/libzip/reorder-i586 - makefiles/sun/xawt/ToBin.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/sql/SQLPermission.java ! src/share/classes/java/util/PropertyPermission.java ! src/share/classes/javax/net/ssl/SSLPermission.java - src/share/classes/sun/net/www/protocol/gopher/GopherClient.java - src/share/classes/sun/net/www/protocol/gopher/Handler.java Changeset: d7ed56d57d97 Author: mullan Date: 2012-11-26 08:34 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d7ed56d57d97 Merge Changeset: c2e80176a697 Author: mduigou Date: 2012-11-26 15:08 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c2e80176a697 8001634: Initial set of functional interface types Summary: Add the core functional interfaces used by the JSR335 libraries. Reviewed-by: dholmes, briangoetz, darcy ! make/docs/CORE_PKGS.gmk ! make/java/java/Makefile + src/share/classes/java/util/function/BinaryOperator.java + src/share/classes/java/util/function/Block.java + src/share/classes/java/util/function/DoubleBinaryOperator.java + src/share/classes/java/util/function/DoubleBlock.java + src/share/classes/java/util/function/DoubleFunction.java + src/share/classes/java/util/function/DoubleSupplier.java + src/share/classes/java/util/function/DoubleUnaryOperator.java + src/share/classes/java/util/function/Function.java + src/share/classes/java/util/function/IntBinaryOperator.java + src/share/classes/java/util/function/IntBlock.java + src/share/classes/java/util/function/IntFunction.java + src/share/classes/java/util/function/IntSupplier.java + src/share/classes/java/util/function/IntUnaryOperator.java + src/share/classes/java/util/function/LongBinaryOperator.java + src/share/classes/java/util/function/LongBlock.java + src/share/classes/java/util/function/LongFunction.java + src/share/classes/java/util/function/LongSupplier.java + src/share/classes/java/util/function/LongUnaryOperator.java + src/share/classes/java/util/function/Predicate.java + src/share/classes/java/util/function/Supplier.java + src/share/classes/java/util/function/UnaryOperator.java + src/share/classes/java/util/function/package-info.java Changeset: ddf97baea570 Author: chegar Date: 2012-11-27 17:15 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ddf97baea570 8003833: Spurious NPE from Socket.getIn/OutputStream Reviewed-by: alanb, dsamersoff ! src/share/classes/java/net/AbstractPlainSocketImpl.java + test/java/net/Socket/Streams.java Changeset: 40311b5f478f Author: robm Date: 2012-11-28 00:47 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/40311b5f478f 8003597: TEST_BUG: Eliminate dependency on javaweb from closed net tests Reviewed-by: chegar + test/java/net/ResponseCache/Test.java + test/java/net/Socket/B6210227.java Changeset: 39b25d5880c6 Author: sherman Date: 2012-11-27 21:51 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/39b25d5880c6 4235519: Make sun.misc.BASE64{De,En}coder classes public Summary: to add java.util.Base64 Reviewed-by: alanb, mduigou ! make/java/java/FILES_java.gmk Changeset: c6ed2c238d4f Author: sherman Date: 2012-11-27 22:07 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c6ed2c238d4f 8004088: hg push for bug#4235519 failed to push all files Summary: pushed all base64 files Reviewed-by: alanb, mduigou + src/share/classes/java/util/Base64.java + test/java/util/Base64/TestBase64.java + test/java/util/Base64/TestBase64Golden.java + test/java/util/Base64/baseEncode.txt + test/java/util/Base64/mimeEncode.txt + test/java/util/Base64/plain.txt + test/java/util/Base64/urlEncode.txt Changeset: 46c627801490 Author: xuelei Date: 2012-11-28 05:18 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/46c627801490 8004019: Removes unused method HandshakeHash.setCertificateVerifyAlg() Summary: certification verification in HandshakeHash was abandoned during TLS 1.2 implementation Reviewed-by: xuelei, weijun Contributed-by: Florian Weimer ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/HandshakeHash.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/MAC.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java Changeset: 735b93462eed Author: jfranck Date: 2012-11-28 09:21 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/735b93462eed 7154390: Add support for repeating annotations in j.l.r.AnnotatedElement Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/Package.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/annotation/ContainedBy.java ! src/share/classes/java/lang/annotation/ContainerFor.java + src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java ! src/share/classes/java/lang/reflect/AccessibleObject.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java + src/share/classes/sun/reflect/annotation/AnnotationSupport.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java + test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java + test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java + test/java/lang/annotation/repeatingAnnotations/subpackage/Container.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainer.java + test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedNonRepeated.java + test/java/lang/annotation/repeatingAnnotations/subpackage/NonRepeated.java + test/java/lang/annotation/repeatingAnnotations/subpackage/package-info.java Changeset: 3b6a2fe6d75c Author: dfuchs Date: 2012-11-28 15:14 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3b6a2fe6d75c 8003476: Cleanup warnings in com.sun.jmx.snmp code Reviewed-by: alanb, smarks ! src/share/classes/com/sun/jmx/snmp/EnumRowStatus.java ! src/share/classes/com/sun/jmx/snmp/Enumerated.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/AclImpl.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMAclBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMInformBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JDMTrapBlock.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/JJTParserState.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/Parser.java ! src/share/classes/com/sun/jmx/snmp/IPAcl/SnmpAcl.java ! src/share/classes/com/sun/jmx/snmp/InetAddressAcl.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpErrorHandlerAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpGenericObjectServer.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpIndex.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMib.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibAgent.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibGroup.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibOid.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibRequestImpl.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibSubRequest.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpMibTable.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpRequestTree.java ! src/share/classes/com/sun/jmx/snmp/agent/SnmpStandardObjectServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/CommunicatorServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServer.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpAdaptorServerMBean.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpMibTree.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/daemon/SnmpSubBulkRequestHandler.java ! src/share/classes/com/sun/jmx/snmp/defaults/SnmpProperties.java ! src/share/classes/com/sun/jmx/snmp/tasks/ThreadService.java ! src/share/classes/sun/management/snmp/AdaptorBootstrap.java Changeset: 262b3b2f3aa3 Author: dfuchs Date: 2012-11-28 10:08 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/262b3b2f3aa3 Merge Changeset: 09bef1e118e3 Author: mchung Date: 2012-11-28 10:49 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/09bef1e118e3 8003851: MethodHandleNatives dependency on java.sql.DriverManager Reviewed-by: alanb, dholmes ! src/share/classes/java/lang/invoke/MethodHandleNatives.java Changeset: 80ddee59a21d Author: mchung Date: 2012-11-28 10:50 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/80ddee59a21d 8003869: Eliminate java.lang.invoke.InnerClassLambdaMetafactory dependency on java.util.logging Reviewed-by: alanb, dholmes ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java Changeset: 13ec794734f5 Author: michaelm Date: 2012-11-29 09:41 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/13ec794734f5 7200720: crash in net.dll during NTLM authentication Reviewed-by: chegar, dsamersoff ! make/java/net/Makefile ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c Changeset: ba5eabd6a37b Author: michaelm Date: 2012-11-29 09:47 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ba5eabd6a37b Merge Changeset: 2b829a5a46ee Author: jgish Date: 2012-11-29 12:28 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2b829a5a46ee 8003380: Compiler warnings in logging test code Summary: Use generics, suppress warnings where appropriate, remove unused imports, etc. Reviewed-by: lancea, chegar ! test/java/util/logging/ClassLoaderLeakTest.java ! test/java/util/logging/Listeners.java ! test/java/util/logging/ListenersWithSM.java ! test/java/util/logging/LoggerResourceBundleRace.java ! test/java/util/logging/LoggingDeadlock2.java ! test/java/util/logging/LoggingDeadlock3.java ! test/java/util/logging/LoggingDeadlock4.java ! test/java/util/logging/LoggingMXBeanTest.java ! test/java/util/logging/LoggingMXBeanTest2.java ! test/java/util/logging/MemoryHandlerTest.java ! test/java/util/logging/ParentLoggersTest.java ! test/java/util/logging/SimpleFormatterFormat.java Changeset: d91e6cb1da41 Author: shade Date: 2012-11-29 17:03 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d91e6cb1da41 8004141: UnsafeStaticFieldAccessorImpl#base should be final Reviewed-by: chegar, alanb Contributed-by: peter.levart at gmail.com ! src/share/classes/sun/reflect/UnsafeStaticFieldAccessorImpl.java Changeset: bf6ceb6b8f80 Author: mduigou Date: 2012-11-29 14:07 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bf6ceb6b8f80 7175464: entrySetView field is never updated in NavigableSubMap Summary: The method entrySet() in AscendingSubMap and DescendingSubMap failed to cache the entrySetView. Reviewed-by: alanb, psandoz ! src/share/classes/java/util/TreeMap.java Changeset: 75cb07a7b622 Author: mduigou Date: 2012-11-29 14:09 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/75cb07a7b622 6553074: String{Buffer,Builder}.indexOf(Str, int) contains unnecessary allocation Summary: It is not necessary to extract the value array with toCharArray. The value array can now be used directly. Reviewed-by: alanb ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java Changeset: 83d9f30ebeed Author: smarks Date: 2012-11-28 17:31 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/83d9f30ebeed 8004131: move jdi tests out of core testset Reviewed-by: alanb, chegar ! make/jprt.properties Changeset: 7ccf93c60c4d Author: smarks Date: 2012-11-29 14:43 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7ccf93c60c4d 8004134: More ProblemList.txt updates (11/2012) Reviewed-by: alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt Changeset: 55f8ddc2f9c6 Author: sla Date: 2012-11-30 08:17 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/55f8ddc2f9c6 7155168: java/util/TimeZone/Bug6912560.java: expected Asia/Tokyo Reviewed-by: okutsu ! test/java/util/TimeZone/Bug6912560.java Changeset: e988de7465d4 Author: zhangshj Date: 2012-11-30 17:24 +0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e988de7465d4 8004211: Remove unused dlinfo local variable in launcher code Reviewed-by: alanb ! src/solaris/bin/java_md_solinux.c Changeset: 72d3d07b625d Author: alanb Date: 2012-11-30 11:18 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/72d3d07b625d 8003949: LogManager, downgrade normative reference to ${java.home}/lib/logging.properties Reviewed-by: psandoz, mchung ! src/share/classes/java/util/logging/LogManager.java Changeset: c370048be8fc Author: alanb Date: 2012-11-30 16:29 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c370048be8fc 7165762: (aio) Default thread pool should be configured so that threads terminated after a timeout period Reviewed-by: chegar ! src/share/classes/sun/nio/ch/ThreadPool.java Changeset: e7edb0da9c6a Author: jfranck Date: 2012-11-30 09:47 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e7edb0da9c6a 8004110: Remove debug code form sun/reflect/annotation/AnnotationSupport.java Reviewed-by: jjg, darcy ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java Changeset: 43d2e02c4098 Author: khazra Date: 2012-11-30 12:00 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/43d2e02c4098 7197662: (prefs) java/util/prefs/AddNodeChangeListener.java fails by timeout or by "couldn't get file lock" Summary: Set -Djava.util.prefs.userRoot to current working directory of user in the prefs tests Reviewed-by: alanb, chegar, weijun, dxu ! test/java/util/prefs/AddNodeChangeListener.java ! test/java/util/prefs/CheckUserPrefsStorage.sh ! test/java/util/prefs/CommentsInXml.java ! test/java/util/prefs/ConflictInFlush.java ! test/java/util/prefs/ExportNode.java ! test/java/util/prefs/ExportSubtree.java ! test/java/util/prefs/PrefsSpi.sh ! test/java/util/prefs/RemoveNullKeyCheck.java ! test/java/util/prefs/RemoveReadOnlyNode.java ! test/java/util/prefs/RemoveUnregedListener.java Changeset: e66ec5b8c15e Author: lana Date: 2012-11-30 16:33 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e66ec5b8c15e Merge Changeset: fd8ba2d8baec Author: sherman Date: 2012-12-01 11:36 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/fd8ba2d8baec 8004212: java.util.Base64 methods decodeArray and decodeBuffer should return the number of bytes written Summary: to return the length instead of position Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java Changeset: f657adf4fe78 Author: alanb Date: 2012-12-02 16:37 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f657adf4fe78 8003846: Override mechanism for currency data should not require creating currency.properties in java.home Reviewed-by: naoto ! src/share/classes/java/util/Currency.java ! test/java/util/Currency/PropertiesTest.java ! test/java/util/Currency/PropertiesTest.sh Changeset: 60550cd2b527 Author: dholmes Date: 2012-12-02 19:16 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/60550cd2b527 7200297: agent code does not handle multiple boot library path elements correctly Summary: When bug 6819213 was fixed it enabled sun.boot.library.path property to contain multiple paths. Code in agents does not handle multiple paths when attempting to find dependent shared libs. Reviewed-by: dholmes, sspitsyn, dsamersoff Contributed-by: Bill Pittore ! src/share/back/debugInit.c ! src/share/back/error_messages.c ! src/share/back/transport.c ! src/share/demo/jvmti/hprof/hprof.h ! src/share/demo/jvmti/hprof/hprof_init.c ! src/solaris/back/linker_md.c ! src/solaris/demo/jvmti/hprof/hprof_md.c ! src/solaris/npt/npt_md.h ! src/windows/back/linker_md.c ! src/windows/demo/jvmti/hprof/hprof_md.c ! src/windows/npt/npt_md.h Changeset: a42da685dfca Author: weijun Date: 2012-12-03 17:14 +0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a42da685dfca 7198507: [TEST_BUG] sun/security/tools/keytool/console.sh should be rewritten Reviewed-by: xuelei ! test/sun/security/tools/keytool/console.sh Changeset: ead651efb271 Author: xuelei Date: 2012-12-03 06:00 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ead651efb271 8004184: security tests leave JSSEServer running Summary: Use othervm mode to release resources, and correct the system properties issues in JSSE Reviewed-by: chegar ! test/sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java Changeset: ee9846f351d7 Author: mullan Date: 2012-12-03 11:07 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ee9846f351d7 7199143: RFE: OCSP revocation checker should provide possibility to specify connection timeout Summary: Added com.sun.security.ocsp.timeout system property to control timeout Reviewed-by: mullan, vinnie Contributed-by: jason.uh at oracle.com ! src/share/classes/sun/security/provider/certpath/OCSP.java Changeset: 38ec2838dd86 Author: dxu Date: 2012-12-04 14:07 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/38ec2838dd86 7142921: (fs) Files.probeContentType reports a MIME type of "text/plain" on Ubuntu 11.04 7144997: (fs) Files.probeContentType returns null on Solaris 64-bit Reviewed-by: alanb, mduigou ! make/java/nio/Makefile ! make/java/nio/mapfile-linux ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/mapfiles/libnio/mapfile-linux ! src/solaris/classes/sun/nio/fs/BsdFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/MacOSXFileSystemProvider.java + src/solaris/classes/sun/nio/fs/MagicFileTypeDetector.java + src/solaris/classes/sun/nio/fs/MimeTypesFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java + src/solaris/native/sun/nio/fs/MagicFileTypeDetector.c Changeset: 2e8863c4f7d0 Author: kmo Date: 2012-12-04 15:10 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2e8863c4f7d0 8004066: TEST_BUG: test/java/lang/Math/DivModTests.java assumes ArithmeticException message Reviewed-by: twisti, alanb, dholmes ! test/java/lang/Math/DivModTests.java Changeset: 87028eb3f020 Author: lana Date: 2012-12-04 11:46 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/87028eb3f020 Merge Changeset: b68a5404de60 Author: lana Date: 2012-12-10 20:58 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b68a5404de60 Merge ! makefiles/CompileJavaClasses.gmk - src/share/classes/sun/awt/TextureSizeConstraining.java Changeset: 285a0954f841 Author: mduigou Date: 2012-12-11 17:22 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/285a0954f841 Merge ! .hgtags ! make/docs/CORE_PKGS.gmk ! make/java/java/FILES_java.gmk ! make/java/java/Makefile ! make/java/nio/Makefile ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Block.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/java/util/function/Supplier.java ! src/share/classes/java/util/function/UnaryOperator.java ! src/share/classes/java/util/function/package-info.java - src/share/classes/sun/awt/TextureSizeConstraining.java From scolebourne at joda.org Wed Dec 12 00:12:06 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 12 Dec 2012 08:12:06 +0000 Subject: Review Request: 8004201: add reducers to primitive type wrappers In-Reply-To: <50C78F58.70705@oracle.com> References: <50B8FE8A.2030403@oracle.com> <50BC0576.4070202@oracle.com> <50BFBC49.9020200@oracle.com> <50BFDC75.6000306@oracle.com> <50C67417.2030205@oracle.com> <50C78F58.70705@oracle.com> Message-ID: Can the sum() static method be written as a plus instance methods? public Integer plus(Integer other) { return value + other; } This would be more useful outside of Project Lambda, and as I understand it, can still be used as a method reference taking two Integers and returning one Integer. I guess sum() could stay for avoiding boxing? Separately, there is no "subtract" method (static or instance), or "negate" method (static or instance), or multipliedBy/dividedBy etc. Providing some but not all of the basic primitives is something the JDK has a habit of doing... it would be nice to get the complete set this time. Stephen On 11 December 2012 19:54, Akhil Arora wrote: > http://cr.openjdk.java.net/~akhil/8004201.3/webrev/ > > - removed these operators on Byte and Short > - javadoc improvements based on CCC review > > > On 12/10/2012 03:45 PM, Akhil Arora wrote: >> >> http://cr.openjdk.java.net/~akhil/8004201.2/webrev/ >> >> - replaced "Suitable for conversion as a method reference to functional >> interfaces such as ..." with @see java.util.function.BinaryOperator >> >> - javadoc - replaced 'a argument'/'another argument' with >> 'the first operand'/'the second operand' >> >> - did not widen return types - widening the return type makes these >> methods unusable as reducers, since BinaryOperator is declared >> T operate(T left, T right) >> >> Thanks >> >> On 12/05/2012 03:44 PM, Joseph Darcy wrote: >>> >>> Akhil, >>> >>> In javadoc like this >>> >>> 298 * as {@code BinaryOperator<Boolean>}. >>> >>> you don't have to use "<" and the like inside {@code}; please >>> change to >>> >>> 298 * as {@code BinaryOperator}. >>> >>> As a general comment, if the operations for primitive type Foo are put >>> into java.lang.Foo, then the type of the operation needs to be >>> explicitly represented in the expression calling the method (unless >>> static imports are used, etc.). Therefore, I suggest putting these sort >>> of static methods all into one class to allow overloading to do its >>> thing (java.lang.Operators?). Also, for methods like sum, I think it is >>> worth considering returning a larger type than the operands to avoid >>> problems from integer or floating-point overflow. For example, sum on >>> byte and short would return int, sun on int would return long, etc. >>> >>> As an aside, to get a numerically robust result, the summation logic >>> over a set of doubles needs to be more than just a set of raw double >>> additions, but that can be tackled later. >>> >>> Cheers, >>> >>> -Joe >>> >>> >>> On 12/5/2012 1:27 PM, Akhil Arora wrote: >>>> >>>> Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/ >>>> >>>> - delegate to Math.min/max for int/long/float/double >>>> - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor >>>> - removed Character variants of min/max/sum >>>> >>>> On 12/02/2012 05:50 PM, David Holmes wrote: >>>>> >>>>> Hi Akhil, >>>>> >>>>> Is it really necessary/desirable to flag all of these as " Suitable for >>>>> conversion as a method reference to functional interfaces such as >>>>> ..." ? >>>> >>>> Not necessary, but it does provide a hint as to their intended use to a >>>> casual browser of these docs. >>>> >>>>> This style: >>>>> >>>>> + * @param a a boolean argument. >>>>> + * @param b another boolean argument. >>>>> >>>>> is at odds with the style used elsewhere for new Functional APIs, and >>>>> with the style of other methods in these classes. Can we just use >>>>> "first >>>>> operand" and "second operand" for all of these? >>>> >>>> It is consistent with Math.min/max, which use the a/b style. Since these >>>> methods are not in one of the functional package, is'nt it better to >>>> stick to the local style? >>>> >>>>> Character.sum does not make sense to me. Who adds together characters? >>>>> I'm not even sure min and max are worth supporting for Character. >>>> >>>> Good point - removed these methods for Character. >>>> >>>>> I disagree with other suggestions to use the Math functions for >>>>> float/double. I think all these methods should use the underlying >>>>> primitive operator regardless of type. >>>> >>>> Are you disagreeing only for float/double or for int/long also? Can you >>>> provide more information as to why you disagree? >>>> >>>> Thanks >>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>> On 1/12/2012 4:44 AM, Akhil Arora wrote: >>>>>> >>>>>> Hi >>>>>> >>>>>> Requesting review for some basic functionality related to lambdas - >>>>>> >>>>>> Add min, max, sum methods to the primitive wrapper classes - Byte, >>>>>> Short, Integer, Long, Float, Double and Character so as to be able to >>>>>> use them as reducers in lambda expressions. Add and, or, xor >>>>>> methods to >>>>>> Boolean. >>>>>> >>>>>> http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ >>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004201 >>>>>> >>>>>> Thanks >>>> >>>> >>> >> > From scolebourne at joda.org Wed Dec 12 00:40:32 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 12 Dec 2012 08:40:32 +0000 Subject: Feedback from JSR-310 Message-ID: >From using default methods in interfaces. I found that pretty much all the calls to super.someDefault() have to be qualified by the interface type - Intface.super.someDefault(). Perhaps this is required now? If not, maybe it should be required (reduces risk of change in behaviour if a superclass later adds the method with the same signature)? I also found that I had an interface, abstract class, concrete class hierarchy, where I wanted to use the default interface method from the concrete class. To do this, I had to add the "implements" clause to the concrete class even though it was already implemented by the abstract class. This felt wrong. I understand the reluctance to allow super calls jumping up the chain, but I think for interfaces the risk seems lower (only behaviour, not state). http://hg.openjdk.java.net/threeten/threeten/jdk/file/e951160d841c/src/share/classes/javax/time/chrono/global/ThaiBuddhistDate.java Had to add implements ChronoLocalDate Stephen From scolebourne at joda.org Wed Dec 12 00:58:35 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 12 Dec 2012 08:58:35 +0000 Subject: sum of numbers using Primitives range In-Reply-To: References: <50C7E40C.8090202@oracle.com> Message-ID: I suspect there may be some previous expectation about integer ranges being inclusive. Just looking at that code, that is what I would have presumed. Sadly, Groovy's documentation is unclear http://groovy.codehaus.org/api/groovy/lang/IntRange.html While Guava requires the user to choose http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Range.html At the very least I think that this signature (with no Javadoc) public static IntStream range(final int from, final int upTo) would be better as public static IntStream range(final int startInclusive, final int endExclusive) As a side note, this is a problem with JSR-310 too. Users generally want date ranges to be inclusive of the end (from Tue to Thu means 3 whole days, but time ranges are exclusive of the end (from 9am to 5pm, generally means you shouldn't expect to accept 5pm). (310 does not currently have ranges in part because of this) Stephen On 12 December 2012 02:10, Arul Dhesiaseelan wrote: > My bad, I was assuming inclusive. Thanks Brian. > > > On Tue, Dec 11, 2012 at 3:55 PM, Brian Goetz wrote: > >> 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 = 45. Ranges are half-open. As in, >> >> for (int i=0; i<10; i++) { ... } >> >> >> >> >> On 12/11/2012 8:46 PM, Arul Dhesiaseelan wrote: >> >>> Sum of integers over using a Primitives range returns invalid result. >>> >>> range(1, 10).map(operand -> operand).sum(); >>> range(1, 10).reduce(0, Integer::sum); >>> range(1, 10).sum(); >>> >>> >>> They all yield 45, instead of 55. Is this a bug? >>> >>> -Arul >>> >>> > From ian.clough at oracle.com Wed Dec 12 01:15:22 2012 From: ian.clough at oracle.com (Ian Clough) Date: Wed, 12 Dec 2012 09:15:22 +0000 Subject: sum of numbers using Primitives range In-Reply-To: References: <50C7E40C.8090202@oracle.com> Message-ID: <50C84B2A.6020700@oracle.com> Isn't this because time (and date/time) is continuous whereas integers and dates aren't and in a sense 9am to 5pm includes 4:59:60 but excludes 5:00:00 although both actually represent the same time. On 12/12/2012 08:58, Stephen Colebourne wrote: > I suspect there may be some previous expectation about integer ranges > being inclusive. Just looking at that code, that is what I would have > presumed. > > Sadly, Groovy's documentation is unclear > http://groovy.codehaus.org/api/groovy/lang/IntRange.html > > While Guava requires the user to choose > http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/Range.html > > At the very least I think that this signature (with no Javadoc) > public static IntStream range(final int from, final int upTo) > would be better as > public static IntStream range(final int startInclusive, final int endExclusive) > > As a side note, this is a problem with JSR-310 too. Users generally > want date ranges to be inclusive of the end (from Tue to Thu means 3 > whole days, but time ranges are exclusive of the end (from 9am to 5pm, > generally means you shouldn't expect to accept 5pm). (310 does not > currently have ranges in part because of this) > > Stephen > > > On 12 December 2012 02:10, Arul Dhesiaseelan wrote: >> My bad, I was assuming inclusive. Thanks Brian. >> >> >> On Tue, Dec 11, 2012 at 3:55 PM, Brian Goetz wrote: >> >>> 1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 = 45. Ranges are half-open. As in, >>> >>> for (int i=0; i<10; i++) { ... } >>> >>> >>> >>> >>> On 12/11/2012 8:46 PM, Arul Dhesiaseelan wrote: >>> >>>> Sum of integers over using a Primitives range returns invalid result. >>>> >>>> range(1, 10).map(operand -> operand).sum(); >>>> range(1, 10).reduce(0, Integer::sum); >>>> range(1, 10).sum(); >>>> >>>> >>>> They all yield 45, instead of 55. Is this a bug? >>>> >>>> -Arul >>>> >>>> > > From peter.levart at gmail.com Wed Dec 12 01:49:38 2012 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 12 Dec 2012 10:49:38 +0100 Subject: Request for binary search using functions In-Reply-To: References: Message-ID: <50C85332.3060107@gmail.com> On 12/11/2012 08:25 PM, Julian Hyde wrote: > On Dec 9, 2012, at 8:48 PM, Cleber Muramoto wrote: > >> Hello, every once in a while I come across the problem of having to use an >> incompatible key to perform a binary search, e.g.: >> >> int binarySearch(SimpleDateFormat[] array,String pattern){ >> ... >> String midVal = array[i].toPattern(); >> ... >> } >> >> (array is sorted using (l,r)->l.toPattern().compareTo(r.toPattern()) ) > I think an AbstractList does the trick. It maps values to strings, and only incurs one allocation per search. You need to make it implement RandomAccess so that binarySearch uses an efficient algorithm. > > final SimpleDateFormat[] array; > final String seek; > class AbstractRandomAccessList extends AbstractList implements RandomAccess {}; > > return Collections.binarySearch( > new AbstractRandomAccessList() { > public int size() { > return array.length; > } > public String get(int index) { > return array[index].toPattern(); > }, > seek); > > There's also a variant Collections.binarySearch(Object[], int, int) if you wish to search on ranges. > > Aside: AbstractList is so useful; it's a shame it is a DAM and not a SAM, and therefore not eligible for lambdafication. Does anyone have any bright ideas how the above could be expressed in lambdas? > > Julian > Like that? public class Arrays { ... public static List asMappedImmutableList(final F[] array, final Function mapper) { return new AbstractList() { @Override public T get(int index) { return mapper.apply(array[index]); } @Override public int size() { return array.length; } }; } ... } Peter From elena.votchennikova at oracle.com Wed Dec 12 03:26:55 2012 From: elena.votchennikova at oracle.com (elena votchennikova) Date: Wed, 12 Dec 2012 15:26:55 +0400 Subject: Behavior of allMatch, anyMatch and noneMatch for empty Stream Message-ID: <50C869FF.80600@oracle.com> Hi, please clarify behavior of allMatch(Predicate), anyMatch(Predicate) and noneMatch(Predicate) methods for empty Stream. 1) Please look at the next code: System.out.println(Streams.emptyStream().allMatch(o -> true)); System.out.println(Streams.emptyStream().anyMatch(o -> true)); System.out.println(Streams.emptyStream().noneMatch(o -> true)); The result output will be: true false true Is it OK? And will such behavior be specified? 2) Methods allMatch, anyMatch and noneMatch throw NullPointerException if Predicate is null, for example: Stream notEmptyStream = Arrays.stream(new Object[] {new Object()}); notEmptyStream.allMatch(null); But if Stream is empty methods will not throw NPE. So, next code will print same result as in point 1) System.out.println(Streams.emptyStream().allMatch(null)); System.out.println(Streams.emptyStream().anyMatch(null)); System.out.println(Streams.emptyStream().noneMatch(null)); Is it OK or calling these methods with null-Predicate should throws NPE? Best regards, Elena From sergey.kuksenko at oracle.com Wed Dec 12 03:31:50 2012 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Wed, 12 Dec 2012 15:31:50 +0400 Subject: sum of numbers using Primitives range In-Reply-To: References: <50C7E40C.8090202@oracle.com> Message-ID: <50C86B26.7000205@oracle.com> > public static IntStream range(final int startInclusive, final int endExclusive) > So, there is no way to get IntStream from zero to and including Integer.MAX_VALUE. -- Best regards, Sergey Kuksenko From ricky.clarkson at gmail.com Wed Dec 12 04:08:12 2012 From: ricky.clarkson at gmail.com (Ricky Clarkson) Date: Wed, 12 Dec 2012 09:08:12 -0300 Subject: sum of numbers using Primitives range In-Reply-To: <50C86B26.7000205@oracle.com> References: <50C7E40C.8090202@oracle.com> <50C86B26.7000205@oracle.com> Message-ID: I'd suggest rangeInclusive(int from, int to) and rangeExcludesEnd(int from, int until). On Dec 12, 2012 8:32 AM, "Sergey Kuksenko" wrote: > > public static IntStream range(final int startInclusive, final int > endExclusive) > > > So, there is no way to get IntStream from zero to and including > Integer.MAX_VALUE. > > > -- > Best regards, > Sergey Kuksenko > > From sergey.kuksenko at oracle.com Wed Dec 12 04:24:39 2012 From: sergey.kuksenko at oracle.com (Sergey Kuksenko) Date: Wed, 12 Dec 2012 16:24:39 +0400 Subject: sum of numbers using Primitives range In-Reply-To: References: <50C7E40C.8090202@oracle.com> <50C86B26.7000205@oracle.com> Message-ID: <50C87787.3060509@oracle.com> In such case it would be much better to add required methods to Integer class. Integer.valueOf(from).to(toInclusive) Integer.valueOf(from).until(toExclusive) On 12/12/2012 04:08 PM, Ricky Clarkson wrote: > I'd suggest rangeInclusive(int from, int to) and rangeExcludesEnd(int > from, int until). > > On Dec 12, 2012 8:32 AM, "Sergey Kuksenko" > wrote: > > > public static IntStream range(final int startInclusive, final > int endExclusive) > > > So, there is no way to get IntStream from zero to and including > Integer.MAX_VALUE. > > > -- > Best regards, > Sergey Kuksenko > -- Best regards, Sergey Kuksenko From brian.goetz at oracle.com Wed Dec 12 06:14:09 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 12 Dec 2012 09:14:09 -0500 Subject: Feedback from JSR-310 In-Reply-To: References: Message-ID: <50C89131.1020806@oracle.com> > I found that pretty much all the calls to super.someDefault() have to > be qualified by the interface type - Intface.super.someDefault(). > Perhaps this is required now? If not, maybe it should be required > (reduces risk of change in behaviour if a superclass later adds the > method with the same signature)? It is required for calling to interfaces, not required for calling to classes. If you found otherwise, that's a bug -- please report! From brian.goetz at oracle.com Wed Dec 12 06:15:38 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 12 Dec 2012 09:15:38 -0500 Subject: Behavior of allMatch, anyMatch and noneMatch for empty Stream In-Reply-To: <50C869FF.80600@oracle.com> References: <50C869FF.80600@oracle.com> Message-ID: <50C8918A.3000108@oracle.com> These values are correct. All/None match correspond to universal quantification, which can be vacuously satisfied; Any match corresponds to existential quantification, which cannot. On 12/12/2012 6:26 AM, elena votchennikova wrote: > Hi, > > please clarify behavior of allMatch(Predicate), anyMatch(Predicate) and > noneMatch(Predicate) methods for empty Stream. > > 1) Please look at the next code: > System.out.println(Streams.emptyStream().allMatch(o -> true)); > System.out.println(Streams.emptyStream().anyMatch(o -> true)); > System.out.println(Streams.emptyStream().noneMatch(o -> true)); > > The result output will be: > true > false > true > > > Is it OK? And will such behavior be specified? > > 2) Methods allMatch, anyMatch and noneMatch throw NullPointerException > if Predicate is null, for example: > Stream notEmptyStream = Arrays.stream(new Object[] {new Object()}); > notEmptyStream.allMatch(null); > > But if Stream is empty methods will not throw NPE. > So, next code will print same result as in point 1) > System.out.println(Streams.emptyStream().allMatch(null)); > System.out.println(Streams.emptyStream().anyMatch(null)); > System.out.println(Streams.emptyStream().noneMatch(null)); > > Is it OK or calling these methods with null-Predicate should throws NPE? > > > > Best regards, > Elena > From vitalyd at gmail.com Wed Dec 12 06:22:55 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 12 Dec 2012 09:22:55 -0500 Subject: Behavior of allMatch, anyMatch and noneMatch for empty Stream In-Reply-To: <50C8918A.3000108@oracle.com> References: <50C869FF.80600@oracle.com> <50C8918A.3000108@oracle.com> Message-ID: Brian, I think NPE should be thrown when predicate is null irrespective of stream length for consistency sake. Thanks Sent from my phone On Dec 12, 2012 9:16 AM, "Brian Goetz" wrote: > These values are correct. > > All/None match correspond to universal quantification, which can be > vacuously satisfied; Any match corresponds to existential > quantification, which cannot. > > On 12/12/2012 6:26 AM, elena votchennikova wrote: > > Hi, > > > > please clarify behavior of allMatch(Predicate), anyMatch(Predicate) and > > noneMatch(Predicate) methods for empty Stream. > > > > 1) Please look at the next code: > > System.out.println(Streams.emptyStream().allMatch(o -> true)); > > System.out.println(Streams.emptyStream().anyMatch(o -> true)); > > System.out.println(Streams.emptyStream().noneMatch(o -> true)); > > > > The result output will be: > > true > > false > > true > > > > > > Is it OK? And will such behavior be specified? > > > > 2) Methods allMatch, anyMatch and noneMatch throw NullPointerException > > if Predicate is null, for example: > > Stream notEmptyStream = Arrays.stream(new Object[] {new Object()}); > > notEmptyStream.allMatch(null); > > > > But if Stream is empty methods will not throw NPE. > > So, next code will print same result as in point 1) > > System.out.println(Streams.emptyStream().allMatch(null)); > > System.out.println(Streams.emptyStream().anyMatch(null)); > > System.out.println(Streams.emptyStream().noneMatch(null)); > > > > Is it OK or calling these methods with null-Predicate should throws NPE? > > > > > > > > Best regards, > > Elena > > > > From oleksander.demura at gmail.com Wed Dec 12 07:44:48 2012 From: oleksander.demura at gmail.com (Olexandr Demura) Date: Wed, 12 Dec 2012 17:44:48 +0200 Subject: Behavior of allMatch, anyMatch and noneMatch for empty Stream In-Reply-To: References: <50C869FF.80600@oracle.com> <50C8918A.3000108@oracle.com> Message-ID: By some unknown reason I percept null to be effectively equal to any chosen SAM with method defined to throw NPE. e.g. Streams.emptyStream().anyMatch(o -> ((Boolean) null).booleanValue()) 2012/12/12 Vitaly Davidovich > Brian, > > I think NPE should be thrown when predicate is null irrespective of stream > length for consistency sake. > > Thanks > > Sent from my phone > On Dec 12, 2012 9:16 AM, "Brian Goetz" wrote: > > > These values are correct. > > > > All/None match correspond to universal quantification, which can be > > vacuously satisfied; Any match corresponds to existential > > quantification, which cannot. > > > > On 12/12/2012 6:26 AM, elena votchennikova wrote: > > > Hi, > > > > > > please clarify behavior of allMatch(Predicate), anyMatch(Predicate) and > > > noneMatch(Predicate) methods for empty Stream. > > > > > > 1) Please look at the next code: > > > System.out.println(Streams.emptyStream().allMatch(o -> true)); > > > System.out.println(Streams.emptyStream().anyMatch(o -> true)); > > > System.out.println(Streams.emptyStream().noneMatch(o -> true)); > > > > > > The result output will be: > > > true > > > false > > > true > > > > > > > > > Is it OK? And will such behavior be specified? > > > > > > 2) Methods allMatch, anyMatch and noneMatch throw NullPointerException > > > if Predicate is null, for example: > > > Stream notEmptyStream = Arrays.stream(new Object[] {new Object()}); > > > notEmptyStream.allMatch(null); > > > > > > But if Stream is empty methods will not throw NPE. > > > So, next code will print same result as in point 1) > > > System.out.println(Streams.emptyStream().allMatch(null)); > > > System.out.println(Streams.emptyStream().anyMatch(null)); > > > System.out.println(Streams.emptyStream().noneMatch(null)); > > > > > > Is it OK or calling these methods with null-Predicate should throws > NPE? > From peter.levart at gmail.com Wed Dec 12 08:21:55 2012 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 12 Dec 2012 17:21:55 +0100 Subject: Behavior of allMatch, anyMatch and noneMatch for empty Stream In-Reply-To: References: <50C869FF.80600@oracle.com> <50C8918A.3000108@oracle.com> Message-ID: <50C8AF23.2000100@gmail.com> On 12/12/2012 04:44 PM, Olexandr Demura wrote: > By some unknown reason I percept null to be effectively equal to any chosen > SAM with method defined to throw NPE. > e.g. Streams.emptyStream().anyMatch(o -> ((Boolean) null).booleanValue()) Predicate p1 = null; Predicate p2 = o -> ((Boolean) null).booleanValue(); p1 and p2 are indistinguishable if their identities and Object-ness-es are ignored. And we all know we should not compare identities and call Object methods of functions... Peter > > 2012/12/12 Vitaly Davidovich > >> Brian, >> >> I think NPE should be thrown when predicate is null irrespective of stream >> length for consistency sake. >> >> Thanks >> >> Sent from my phone >> On Dec 12, 2012 9:16 AM, "Brian Goetz" wrote: >> >>> These values are correct. >>> >>> All/None match correspond to universal quantification, which can be >>> vacuously satisfied; Any match corresponds to existential >>> quantification, which cannot. >>> >>> On 12/12/2012 6:26 AM, elena votchennikova wrote: >>>> Hi, >>>> >>>> please clarify behavior of allMatch(Predicate), anyMatch(Predicate) and >>>> noneMatch(Predicate) methods for empty Stream. >>>> >>>> 1) Please look at the next code: >>>> System.out.println(Streams.emptyStream().allMatch(o -> true)); >>>> System.out.println(Streams.emptyStream().anyMatch(o -> true)); >>>> System.out.println(Streams.emptyStream().noneMatch(o -> true)); >>>> >>>> The result output will be: >>>> true >>>> false >>>> true >>>> >>>> >>>> Is it OK? And will such behavior be specified? >>>> >>>> 2) Methods allMatch, anyMatch and noneMatch throw NullPointerException >>>> if Predicate is null, for example: >>>> Stream notEmptyStream = Arrays.stream(new Object[] {new Object()}); >>>> notEmptyStream.allMatch(null); >>>> >>>> But if Stream is empty methods will not throw NPE. >>>> So, next code will print same result as in point 1) >>>> System.out.println(Streams.emptyStream().allMatch(null)); >>>> System.out.println(Streams.emptyStream().anyMatch(null)); >>>> System.out.println(Streams.emptyStream().noneMatch(null)); >>>> >> > > Is it OK or calling these methods with null-Predicate should throws >> NPE? >> From vitalyd at gmail.com Wed Dec 12 08:24:21 2012 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 12 Dec 2012 11:24:21 -0500 Subject: Behavior of allMatch, anyMatch and noneMatch for empty Stream In-Reply-To: References: <50C869FF.80600@oracle.com> <50C8918A.3000108@oracle.com> Message-ID: Hmm, that's a different semantic though - the caller is passing an instance of a predicate, not a predicate that throws NPE if invoked. As it stands now, the behavior is inconsistent, possibly confusing at runtime, and unintuitive, IMHO. FWIW, .NET's analog explicitly checks for null (and throws) input before iterating. Sent from my phone On Dec 12, 2012 10:44 AM, "Olexandr Demura" wrote: > By some unknown reason I percept null to be effectively equal to any > chosen SAM with method defined to throw NPE. > e.g. Streams.emptyStream().anyMatch(o -> ((Boolean) null).booleanValue()) > > 2012/12/12 Vitaly Davidovich > >> Brian, >> >> I think NPE should be thrown when predicate is null irrespective of stream >> length for consistency sake. >> >> Thanks >> >> Sent from my phone >> On Dec 12, 2012 9:16 AM, "Brian Goetz" wrote: >> >> > These values are correct. >> > >> > All/None match correspond to universal quantification, which can be >> > vacuously satisfied; Any match corresponds to existential >> > quantification, which cannot. >> > >> > On 12/12/2012 6:26 AM, elena votchennikova wrote: >> > > Hi, >> > > >> > > please clarify behavior of allMatch(Predicate), anyMatch(Predicate) >> and >> > > noneMatch(Predicate) methods for empty Stream. >> > > >> > > 1) Please look at the next code: >> > > System.out.println(Streams.emptyStream().allMatch(o -> true)); >> > > System.out.println(Streams.emptyStream().anyMatch(o -> true)); >> > > System.out.println(Streams.emptyStream().noneMatch(o -> true)); >> > > >> > > The result output will be: >> > > true >> > > false >> > > true >> > > >> > > >> > > Is it OK? And will such behavior be specified? >> > > >> > > 2) Methods allMatch, anyMatch and noneMatch throw NullPointerException >> > > if Predicate is null, for example: >> > > Stream notEmptyStream = Arrays.stream(new Object[] {new Object()}); >> > > notEmptyStream.allMatch(null); >> > > >> > > But if Stream is empty methods will not throw NPE. >> > > So, next code will print same result as in point 1) >> > > System.out.println(Streams.emptyStream().allMatch(null)); >> > > System.out.println(Streams.emptyStream().anyMatch(null)); >> > > System.out.println(Streams.emptyStream().noneMatch(null)); >> > > >> > > Is it OK or calling these methods with null-Predicate should throws >> NPE? >> > From forax at univ-mlv.fr Wed Dec 12 08:48:06 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 12 Dec 2012 17:48:06 +0100 Subject: Behavior of allMatch, anyMatch and noneMatch for empty Stream In-Reply-To: References: <50C869FF.80600@oracle.com> <50C8918A.3000108@oracle.com> Message-ID: <50C8B546.10101@univ-mlv.fr> On 12/12/2012 03:22 PM, Vitaly Davidovich wrote: > Brian, > > I think NPE should be thrown when predicate is null irrespective of stream > length for consistency sake. > > Thanks yes, it this should be true for any parameters that are typed by a functional interface at least in java.util and java.util.stream. We don't want user to send null as a lambda exactly like we don't want user to send a null enum. R?mi > > Sent from my phone > On Dec 12, 2012 9:16 AM, "Brian Goetz" wrote: > >> These values are correct. >> >> All/None match correspond to universal quantification, which can be >> vacuously satisfied; Any match corresponds to existential >> quantification, which cannot. >> >> On 12/12/2012 6:26 AM, elena votchennikova wrote: >>> Hi, >>> >>> please clarify behavior of allMatch(Predicate), anyMatch(Predicate) and >>> noneMatch(Predicate) methods for empty Stream. >>> >>> 1) Please look at the next code: >>> System.out.println(Streams.emptyStream().allMatch(o -> true)); >>> System.out.println(Streams.emptyStream().anyMatch(o -> true)); >>> System.out.println(Streams.emptyStream().noneMatch(o -> true)); >>> >>> The result output will be: >>> true >>> false >>> true >>> >>> >>> Is it OK? And will such behavior be specified? >>> >>> 2) Methods allMatch, anyMatch and noneMatch throw NullPointerException >>> if Predicate is null, for example: >>> Stream notEmptyStream = Arrays.stream(new Object[] {new Object()}); >>> notEmptyStream.allMatch(null); >>> >>> But if Stream is empty methods will not throw NPE. >>> So, next code will print same result as in point 1) >>> System.out.println(Streams.emptyStream().allMatch(null)); >>> System.out.println(Streams.emptyStream().anyMatch(null)); >>> System.out.println(Streams.emptyStream().noneMatch(null)); >>> >>> Is it OK or calling these methods with null-Predicate should throws NPE? >>> >>> >>> >>> Best regards, >>> Elena >>> >> From peter.levart at gmail.com Wed Dec 12 10:10:02 2012 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 12 Dec 2012 19:10:02 +0100 Subject: Behavior of allMatch, anyMatch and noneMatch for empty Stream In-Reply-To: <50C8B546.10101@univ-mlv.fr> References: <50C869FF.80600@oracle.com> <50C8918A.3000108@oracle.com> <50C8B546.10101@univ-mlv.fr> Message-ID: But isn't checking for null going to defeat any possible future optimizations that could optimize the object away? Peter On Dec 12, 2012 5:51 PM, "Remi Forax" wrote: > On 12/12/2012 03:22 PM, Vitaly Davidovich wrote: > > Brian, > > > > I think NPE should be thrown when predicate is null irrespective of > stream > > length for consistency sake. > > > > Thanks > > yes, it this should be true for any parameters that are typed by a > functional interface at least in java.util and java.util.stream. > We don't want user to send null as a lambda exactly like we don't want > user to send a null enum. > > R?mi > > > > > Sent from my phone > > On Dec 12, 2012 9:16 AM, "Brian Goetz" wrote: > > > >> These values are correct. > >> > >> All/None match correspond to universal quantification, which can be > >> vacuously satisfied; Any match corresponds to existential > >> quantification, which cannot. > >> > >> On 12/12/2012 6:26 AM, elena votchennikova wrote: > >>> Hi, > >>> > >>> please clarify behavior of allMatch(Predicate), anyMatch(Predicate) and > >>> noneMatch(Predicate) methods for empty Stream. > >>> > >>> 1) Please look at the next code: > >>> System.out.println(Streams.emptyStream().allMatch(o -> true)); > >>> System.out.println(Streams.emptyStream().anyMatch(o -> true)); > >>> System.out.println(Streams.emptyStream().noneMatch(o -> true)); > >>> > >>> The result output will be: > >>> true > >>> false > >>> true > >>> > >>> > >>> Is it OK? And will such behavior be specified? > >>> > >>> 2) Methods allMatch, anyMatch and noneMatch throw NullPointerException > >>> if Predicate is null, for example: > >>> Stream notEmptyStream = Arrays.stream(new Object[] {new Object()}); > >>> notEmptyStream.allMatch(null); > >>> > >>> But if Stream is empty methods will not throw NPE. > >>> So, next code will print same result as in point 1) > >>> System.out.println(Streams.emptyStream().allMatch(null)); > >>> System.out.println(Streams.emptyStream().anyMatch(null)); > >>> System.out.println(Streams.emptyStream().noneMatch(null)); > >>> > >>> Is it OK or calling these methods with null-Predicate should throws > NPE? > >>> > >>> > >>> > >>> Best regards, > >>> Elena > >>> > >> > > > From forax at univ-mlv.fr Wed Dec 12 11:39:59 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 12 Dec 2012 20:39:59 +0100 Subject: Behavior of allMatch, anyMatch and noneMatch for empty Stream In-Reply-To: References: <50C869FF.80600@oracle.com> <50C8918A.3000108@oracle.com> <50C8B546.10101@univ-mlv.fr> Message-ID: <50C8DD8F.1090104@univ-mlv.fr> On 12/12/2012 07:10 PM, Peter Levart wrote: > > But isn't checking for null going to defeat any possible future > optimizations that could optimize the object away? > no, the VM tracks if a reference is effectively null or not. > Peter > R?mi > On Dec 12, 2012 5:51 PM, "Remi Forax" > wrote: > > On 12/12/2012 03:22 PM, Vitaly Davidovich wrote: > > Brian, > > > > I think NPE should be thrown when predicate is null irrespective > of stream > > length for consistency sake. > > > > Thanks > > yes, it this should be true for any parameters that are typed by a > functional interface at least in java.util and java.util.stream. > We don't want user to send null as a lambda exactly like we don't want > user to send a null enum. > > R?mi > > > > > Sent from my phone > > On Dec 12, 2012 9:16 AM, "Brian Goetz" > wrote: > > > >> These values are correct. > >> > >> All/None match correspond to universal quantification, which can be > >> vacuously satisfied; Any match corresponds to existential > >> quantification, which cannot. > >> > >> On 12/12/2012 6:26 AM, elena votchennikova wrote: > >>> Hi, > >>> > >>> please clarify behavior of allMatch(Predicate), > anyMatch(Predicate) and > >>> noneMatch(Predicate) methods for empty Stream. > >>> > >>> 1) Please look at the next code: > >>> System.out.println(Streams.emptyStream().allMatch(o -> true)); > >>> System.out.println(Streams.emptyStream().anyMatch(o -> true)); > >>> System.out.println(Streams.emptyStream().noneMatch(o -> true)); > >>> > >>> The result output will be: > >>> true > >>> false > >>> true > >>> > >>> > >>> Is it OK? And will such behavior be specified? > >>> > >>> 2) Methods allMatch, anyMatch and noneMatch throw > NullPointerException > >>> if Predicate is null, for example: > >>> Stream notEmptyStream = Arrays.stream(new Object[] {new > Object()}); > >>> notEmptyStream.allMatch(null); > >>> > >>> But if Stream is empty methods will not throw NPE. > >>> So, next code will print same result as in point 1) > >>> System.out.println(Streams.emptyStream().allMatch(null)); > >>> System.out.println(Streams.emptyStream().anyMatch(null)); > >>> System.out.println(Streams.emptyStream().noneMatch(null)); > >>> > >>> Is it OK or calling these methods with null-Predicate should > throws NPE? > >>> > >>> > >>> > >>> Best regards, > >>> Elena > >>> > >> > > From richard.warburton at gmail.com Wed Dec 12 12:15:50 2012 From: richard.warburton at gmail.com (Richard Warburton) Date: Wed, 12 Dec 2012 20:15:50 +0000 Subject: Javadoc Link Message-ID: Hey, I've just tried downloading the Javadoc link from http://jdk8.java.net/lambda/ and I get a 404. It links me to " http://download.java.net//download/lambda/b68/lambda-8-b68-apidocs-09_dec_2012.zip ". regards, Richard From r.spilker at gmail.com Wed Dec 12 12:27:09 2012 From: r.spilker at gmail.com (Roel Spilker) Date: Wed, 12 Dec 2012 21:27:09 +0100 Subject: Feedback on the implementation of StringJoiner In-Reply-To: References: <50B8D792.9060601@oracle.com> Message-ID: Well, a lot of code was removed, what is in my opinion always a good thing. Apart from the comments already mentioned, I have one other point. The JavaDoc of length(), charAt(int) and subSequence(int, int) still define their behavior as being equivalent to the same operation on the toString() result. However, the class isn't final. I don't think it is a promise that should be made, because it puts quite a burden on a subclass. My preferred solution would be to make the class final. However, I don't know if that is an option. Roel On Tue, Dec 11, 2012 at 9:54 AM, Stephen Colebourne wrote: > On 10 December 2012 16:26, Henry Jen wrote: > > I am doing some changes to adapt your feedbacks and trying to have > minimum but enough APIs, latest proposed can be found at > > > > http://cr.openjdk.java.net/~henryjen/lambda/StringJoiner.1/webrev/ > > StringJoiner > Line 61 example - missing bracket ) > > First line of some method descriptions starts with lower case rather than > upper. > > Line 260 exception not listed in Javadoc > > As a general rule, I would try very hard to return a String, not a > CharSequence. Accepting a CharSequence on input is OK, but returning > it gives very few guarantees to callers. Think Postels law. > > Stephen > > From r.spilker at gmail.com Wed Dec 12 12:34:09 2012 From: r.spilker at gmail.com (Roel Spilker) Date: Wed, 12 Dec 2012 21:34:09 +0100 Subject: Feedback on the implementation of StringJoiner In-Reply-To: References: <50B8D792.9060601@oracle.com> Message-ID: Oh, and please remove the string concatenation from the constructor. Since prefix and suffix are stored separately and setEmptyOutput does not accept null values, a null-check on the field can be used to calculate the emptyOutput when it is needed. I think the common case is that the emptyOutput value is not read at all. On Wed, Dec 12, 2012 at 9:27 PM, Roel Spilker wrote: > Well, a lot of code was removed, what is in my opinion always a good thing. > > Apart from the comments already mentioned, I have one other point. The > JavaDoc of length(), charAt(int) and subSequence(int, int) still define > their behavior as being equivalent to the same operation on the toString() > result. However, the class isn't final. I don't think it is a promise that > should be made, because it puts quite a burden on a subclass. My preferred > solution would be to make the class final. However, I don't know if that is > an option. > > Roel > > > > On Tue, Dec 11, 2012 at 9:54 AM, Stephen Colebourne wrote: > >> On 10 December 2012 16:26, Henry Jen wrote: >> > I am doing some changes to adapt your feedbacks and trying to have >> minimum but enough APIs, latest proposed can be found at >> > >> > http://cr.openjdk.java.net/~henryjen/lambda/StringJoiner.1/webrev/ >> >> StringJoiner >> Line 61 example - missing bracket ) >> >> First line of some method descriptions starts with lower case rather than >> upper. >> >> Line 260 exception not listed in Javadoc >> >> As a general rule, I would try very hard to return a String, not a >> CharSequence. Accepting a CharSequence on input is OK, but returning >> it gives very few guarantees to callers. Think Postels law. >> >> Stephen >> >> > From r.spilker at gmail.com Wed Dec 12 12:39:56 2012 From: r.spilker at gmail.com (Roel Spilker) Date: Wed, 12 Dec 2012 21:39:56 +0100 Subject: Feedback on the implementation of StringJoiner In-Reply-To: References: <50B8D792.9060601@oracle.com> Message-ID: And subSequence could do a slightly better job: if (start < value.length()) { return new StringBuilder(value.subSequence(start, value.length())) .append(suffix.subSequence(0, end - value.length())) .toString(); is IMHO less performant than: if (start < value.length()) { return new StringBuilder(end - start) .append(value.subSequence(start, value.length())) .append(suffix.subSequence(0, end - value.length())) .toString(); On Wed, Dec 12, 2012 at 9:34 PM, Roel Spilker wrote: > Oh, and please remove the string concatenation from the constructor. Since > prefix and suffix are stored separately and setEmptyOutput does not accept > null values, a null-check on the field can be used to calculate the > emptyOutput when it is needed. I think the common case is that the > emptyOutput value is not read at all. > > > On Wed, Dec 12, 2012 at 9:27 PM, Roel Spilker wrote: > >> Well, a lot of code was removed, what is in my opinion always a good >> thing. >> >> Apart from the comments already mentioned, I have one other point. The >> JavaDoc of length(), charAt(int) and subSequence(int, int) still define >> their behavior as being equivalent to the same operation on the toString() >> result. However, the class isn't final. I don't think it is a promise that >> should be made, because it puts quite a burden on a subclass. My preferred >> solution would be to make the class final. However, I don't know if that is >> an option. >> >> Roel >> >> >> >> On Tue, Dec 11, 2012 at 9:54 AM, Stephen Colebourne > > wrote: >> >>> On 10 December 2012 16:26, Henry Jen wrote: >>> > I am doing some changes to adapt your feedbacks and trying to have >>> minimum but enough APIs, latest proposed can be found at >>> > >>> > http://cr.openjdk.java.net/~henryjen/lambda/StringJoiner.1/webrev/ >>> >>> StringJoiner >>> Line 61 example - missing bracket ) >>> >>> First line of some method descriptions starts with lower case rather >>> than upper. >>> >>> Line 260 exception not listed in Javadoc >>> >>> As a general rule, I would try very hard to return a String, not a >>> CharSequence. Accepting a CharSequence on input is OK, but returning >>> it gives very few guarantees to callers. Think Postels law. >>> >>> Stephen >>> >>> >> > From jonathan.gibbons at oracle.com Wed Dec 12 13:49:12 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 12 Dec 2012 13:49:12 -0800 Subject: Javadoc Link In-Reply-To: References: Message-ID: <50C8FBD8.8060406@oracle.com> On 12/12/2012 12:15 PM, Richard Warburton wrote: > Hey, > > I've just tried downloading the Javadoc link from > http://jdk8.java.net/lambda/ and I get a 404. It links me to " > http://download.java.net//download/lambda/b68/lambda-8-b68-apidocs-09_dec_2012.zip > ". > > regards, > > Richard > Richard, Lambda folk, It looks like the link should be: http://download.java.net/lambda/b68/lambda-8-b68-apidocs-09_dec_2012.zip -- Jon From forax at univ-mlv.fr Thu Dec 13 01:26:32 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 13 Dec 2012 10:26:32 +0100 Subject: Stream perf test Message-ID: <50C99F48.4030709@univ-mlv.fr> I've tried to write several tests that use the stream pipeline and I've troubled to get stable values, sometimes the fastest time is one order magnitude faster than the slowest time. Do we have any perf tests written somewhere to see what I did wrong ? R?mi From forax at univ-mlv.fr Thu Dec 13 01:37:44 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 13 Dec 2012 10:37:44 +0100 Subject: Feedback on the implementation of StringJoiner In-Reply-To: <50C6E9E3.4000506@univ-mlv.fr> References: <50B8D792.9060601@oracle.com> <50C67FD6.2040808@univ-mlv.fr> <50C69761.8050400@oracle.com> <50C6E9E3.4000506@univ-mlv.fr> Message-ID: <50C9A1E8.4020908@univ-mlv.fr> Hi Henry, if we don't change the implementation of StringJoiner now (see my mail about my inability to test the stream pipeline), there are at least two things that can be changed in your current implementation. All the static final String can be removed because the string are interned so there is no need to store then in a static fields. Even if you think the code is more clear with that and you may be right, it's not a standard practice, the only code that does that is String.java (as far as I know). You don't need the field 'somethingAdded' because you can test the length of the StringBuilder (value). cheers, R?mi From aleksey.shipilev at oracle.com Thu Dec 13 01:59:52 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Thu, 13 Dec 2012 13:59:52 +0400 Subject: Stream perf test In-Reply-To: <50C99F48.4030709@univ-mlv.fr> References: <50C99F48.4030709@univ-mlv.fr> Message-ID: <6AA74569-9E4B-4455-B7E4-E79B3A61B533@oracle.com> Hi Remi, We do have lots of perf tests internally (due to legal at this point to open source them), and yes, these are tricky to get right. There seem to be nothing special about the streams per se, just usual micro benchmarking troubles. If you can send your tests along, we can figure whether you are dealing with something we already know about. -Aleksey. On 13.12.2012, at 13:26, Remi Forax wrote: > I've tried to write several tests that use the stream pipeline and I've > troubled to get stable values, sometimes the fastest time is one order > magnitude faster than the slowest time. > Do we have any perf tests written somewhere to see what I did wrong ? > > R?mi > From christian.mallwitz at Commerzbank.com Thu Dec 13 03:30:08 2012 From: christian.mallwitz at Commerzbank.com (Mallwitz, Christian) Date: Thu, 13 Dec 2012 12:30:08 +0100 Subject: skip/limit in parallel context Message-ID: Hi, Using jdk1.8.0-b68-09_dec_2012 and having (this is counting even numbers up to 100 in various ways) import java.util.Arrays; import java.util.stream.Stream; public class LambdaParallelLimitSkip { private static final int n = 100; public static void main(String[] args) { testSerial(); testParallel(); } public static void testSerial() { System.out.println("serial count after limit(10): " + getArrayBasedStream(false) .filter(l -> l%2==0) // filter even numbers .limit(10) .reduce(0L, (left, right) -> left + 1L)); // count System.out.println("serial count after skip(10) : " + getArrayBasedStream(false) .filter(l -> l%2==0) // filter even numbers .skip(10) .reduce(0L, (left, right) -> left + 1L)); // count } public static void testParallel() { System.out.println("parallel count after limit(10): " + getArrayBasedStream(true) .filter(l -> l%2==0) // filter even numbers .limit(10) .reduce(0L, (left, right) -> left + 1L)); // count System.out.println("parallel count after skip(10) : " + getArrayBasedStream(true) .filter(l -> l%2==0) // filter even numbers .skip(10) .reduce(0L, (left, right) -> left + 1L)); // count } public static Stream getArrayBasedStream(boolean parallel) { Long[] list = new Long[n]; for(int i=0; i References: Message-ID: <8C2D1D75-C92B-4171-A16D-7BFD81F67F23@oracle.com> Hi Christian, The problem is you are not combining/merging the counts correctly. The reduction step is different to the combining/merging step. Try this: .reduce(0L, (count, t) -> count + 1L, (countLeft, countRight) -> countLeft + countRight) The first lambda is the reducer, this will be executed on leaf nodes of the computation tree (a sequential stream can be considered a degenerate case of just one leaf node). The second lambda will be executed to combine the results of two nodes. This is a tricky area, it's not entirely a free lunch going from sequential to parallel evaluation with folding or reducing. You need to be aware of the properties of your reducing function (e.g. is it associative or commutative?, are the combining and reducing steps different?, what is the identity element?). Hth, Paul. On Dec 13, 2012, at 12:30 PM, "Mallwitz, Christian" wrote: > Hi, > > Using jdk1.8.0-b68-09_dec_2012 and having (this is counting even numbers up to 100 in various ways) > > import java.util.Arrays; > import java.util.stream.Stream; > > public class LambdaParallelLimitSkip { > > private static final int n = 100; > > public static void main(String[] args) { > testSerial(); > testParallel(); > } > > public static void testSerial() { > System.out.println("serial count after limit(10): " + getArrayBasedStream(false) > .filter(l -> l%2==0) // filter even numbers > .limit(10) > .reduce(0L, (left, right) -> left + 1L)); // count > System.out.println("serial count after skip(10) : " + getArrayBasedStream(false) > .filter(l -> l%2==0) // filter even numbers > .skip(10) > .reduce(0L, (left, right) -> left + 1L)); // count > } > > public static void testParallel() { > System.out.println("parallel count after limit(10): " + getArrayBasedStream(true) > .filter(l -> l%2==0) // filter even numbers > .limit(10) > .reduce(0L, (left, right) -> left + 1L)); // count > System.out.println("parallel count after skip(10) : " + getArrayBasedStream(true) > .filter(l -> l%2==0) // filter even numbers > .skip(10) > .reduce(0L, (left, right) -> left + 1L)); // count > } > > public static Stream getArrayBasedStream(boolean parallel) { > Long[] list = new Long[n]; > for(int i=0; i return parallel ? Arrays.asList(list).parallel() : Arrays.asList(list).stream(); > } > } > > This outputs > > serial count after limit(10): 10 > serial count after skip(10) : 40 > parallel count after limit(10): 7 > parallel count after skip(10) : 25 > > The last item "parallel count after skip(10) : 25" is incorrect - this needs to be in the 40..50 range, doesn't it? > > Now I understand that the Java Doc is saying skip/limit 'at most n elements' but IMHO this is not particular useful. > > skip/limit _could_ consume more than n elements of a source stream (and calling the filter predicate in my example more often in the parallel than serial case) but should do "exactly n" when passing elements to further steps in the processing downstreams. > > Regards > Christian > From maurizio.cimadamore at oracle.com Thu Dec 13 04:35:45 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 13 Dec 2012 12:35:45 +0000 Subject: hg: lambda/lambda/langtools: Cleanup: remove unused LambdaToInner translator Message-ID: <20121213123554.9FA6047106@hg.openjdk.java.net> Changeset: 9762de578ffd Author: mcimadamore Date: 2012-12-13 12:25 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/9762de578ffd Cleanup: remove unused LambdaToInner translator Contributed-by: vicente.romero at oracle.com - src/share/classes/com/sun/tools/javac/comp/LambdaToInnerClass.java - src/share/classes/com/sun/tools/javac/comp/LambdaTranslator.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java From forax at univ-mlv.fr Thu Dec 13 06:12:50 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 13 Dec 2012 15:12:50 +0100 Subject: skip/limit in parallel context In-Reply-To: <8C2D1D75-C92B-4171-A16D-7BFD81F67F23@oracle.com> References: <8C2D1D75-C92B-4171-A16D-7BFD81F67F23@oracle.com> Message-ID: <50C9E262.5000308@univ-mlv.fr> On 12/13/2012 01:13 PM, Paul Sandoz wrote: > Hi Christian, > > The problem is you are not combining/merging the counts correctly. The reduction step is different to the combining/merging step. > > Try this: > > .reduce(0L, (count, t) -> count + 1L, (countLeft, countRight) -> countLeft + countRight) > > The first lambda is the reducer, this will be executed on leaf nodes of the computation tree (a sequential stream can be considered a degenerate case of just one leaf node). The second lambda will be executed to combine the results of two nodes. > > This is a tricky area, it's not entirely a free lunch going from sequential to parallel evaluation with folding or reducing. You need to be aware of the properties of your reducing function (e.g. is it associative or commutative?, are the combining and reducing steps different?, what is the identity element?). > > Hth, > Paul. the main issue here is that, with a sequential stream, you can write .reduce(0L, (count, t) -> count + 1L, null) R?mi > > On Dec 13, 2012, at 12:30 PM, "Mallwitz, Christian" wrote: > >> Hi, >> >> Using jdk1.8.0-b68-09_dec_2012 and having (this is counting even numbers up to 100 in various ways) >> >> import java.util.Arrays; >> import java.util.stream.Stream; >> >> public class LambdaParallelLimitSkip { >> >> private static final int n = 100; >> >> public static void main(String[] args) { >> testSerial(); >> testParallel(); >> } >> >> public static void testSerial() { >> System.out.println("serial count after limit(10): " + getArrayBasedStream(false) >> .filter(l -> l%2==0) // filter even numbers >> .limit(10) >> .reduce(0L, (left, right) -> left + 1L)); // count >> System.out.println("serial count after skip(10) : " + getArrayBasedStream(false) >> .filter(l -> l%2==0) // filter even numbers >> .skip(10) >> .reduce(0L, (left, right) -> left + 1L)); // count >> } >> >> public static void testParallel() { >> System.out.println("parallel count after limit(10): " + getArrayBasedStream(true) >> .filter(l -> l%2==0) // filter even numbers >> .limit(10) >> .reduce(0L, (left, right) -> left + 1L)); // count >> System.out.println("parallel count after skip(10) : " + getArrayBasedStream(true) >> .filter(l -> l%2==0) // filter even numbers >> .skip(10) >> .reduce(0L, (left, right) -> left + 1L)); // count >> } >> >> public static Stream getArrayBasedStream(boolean parallel) { >> Long[] list = new Long[n]; >> for(int i=0; i> return parallel ? Arrays.asList(list).parallel() : Arrays.asList(list).stream(); >> } >> } >> >> This outputs >> >> serial count after limit(10): 10 >> serial count after skip(10) : 40 >> parallel count after limit(10): 7 >> parallel count after skip(10) : 25 >> >> The last item "parallel count after skip(10) : 25" is incorrect - this needs to be in the 40..50 range, doesn't it? >> >> Now I understand that the Java Doc is saying skip/limit 'at most n elements' but IMHO this is not particular useful. >> >> skip/limit _could_ consume more than n elements of a source stream (and calling the filter predicate in my example more often in the parallel than serial case) but should do "exactly n" when passing elements to further steps in the processing downstreams. >> >> Regards >> Christian >> > From christian.mallwitz at Commerzbank.com Thu Dec 13 06:20:28 2012 From: christian.mallwitz at Commerzbank.com (Mallwitz, Christian) Date: Thu, 13 Dec 2012 15:20:28 +0100 Subject: skip/limit in parallel context In-Reply-To: <8C2D1D75-C92B-4171-A16D-7BFD81F67F23@oracle.com> References: <8C2D1D75-C92B-4171-A16D-7BFD81F67F23@oracle.com> Message-ID: Hi Paul, Ah, this helps and it even produces the expected result :-) Your explaination though gets me confused when looking at the javadoc: On java.util.stream.Stream: U reduce(U base, Combiner reducer, BinaryOperator combiner) the reducer (2. param) is a Combiner and the combiner (3. param) is the BinaryOperator ??? I would have at least expect my BinaryOperator '(left, right) -> left + 1L ' from the sequential operation to go to the 3rd parameter. Additionally, I would assume calling "reduce(T base, BinaryOperator op)" on a parallel stream would never make sense, would it? Vice versa: calling "reduce(U base, Combiner reducer, BinaryOperator combiner)" should be reserved for parallel streams as there is no 'combining' on a serial stream? Thanks Christian -----Original Message----- From: lambda-dev-bounces at openjdk.java.net [mailto:lambda-dev-bounces at openjdk.java.net] On Behalf Of Paul Sandoz Sent: Thursday, December 13, 2012 12:13 PM Cc: 'lambda-dev at openjdk.java.net' Subject: Re: skip/limit in parallel context Hi Christian, The problem is you are not combining/merging the counts correctly. The reduction step is different to the combining/merging step. Try this: .reduce(0L, (count, t) -> count + 1L, (countLeft, countRight) -> countLeft + countRight) The first lambda is the reducer, this will be executed on leaf nodes of the computation tree (a sequential stream can be considered a degenerate case of just one leaf node). The second lambda will be executed to combine the results of two nodes. This is a tricky area, it's not entirely a free lunch going from sequential to parallel evaluation with folding or reducing. You need to be aware of the properties of your reducing function (e.g. is it associative or commutative?, are the combining and reducing steps different?, what is the identity element?). Hth, Paul. On Dec 13, 2012, at 12:30 PM, "Mallwitz, Christian" wrote: > Hi, > > Using jdk1.8.0-b68-09_dec_2012 and having (this is counting even numbers up to 100 in various ways) > > import java.util.Arrays; > import java.util.stream.Stream; > > public class LambdaParallelLimitSkip { > > private static final int n = 100; > > public static void main(String[] args) { > testSerial(); > testParallel(); > } > > public static void testSerial() { > System.out.println("serial count after limit(10): " + getArrayBasedStream(false) > .filter(l -> l%2==0) // filter even numbers > .limit(10) > .reduce(0L, (left, right) -> left + 1L)); // count > System.out.println("serial count after skip(10) : " + getArrayBasedStream(false) > .filter(l -> l%2==0) // filter even numbers > .skip(10) > .reduce(0L, (left, right) -> left + 1L)); // count > } > > public static void testParallel() { > System.out.println("parallel count after limit(10): " + getArrayBasedStream(true) > .filter(l -> l%2==0) // filter even numbers > .limit(10) > .reduce(0L, (left, right) -> left + 1L)); // count > System.out.println("parallel count after skip(10) : " + getArrayBasedStream(true) > .filter(l -> l%2==0) // filter even numbers > .skip(10) > .reduce(0L, (left, right) -> left + 1L)); // count > } > > public static Stream getArrayBasedStream(boolean parallel) { > Long[] list = new Long[n]; > for(int i=0; i return parallel ? Arrays.asList(list).parallel() : Arrays.asList(list).stream(); > } > } > > This outputs > > serial count after limit(10): 10 > serial count after skip(10) : 40 > parallel count after limit(10): 7 > parallel count after skip(10) : 25 > > The last item "parallel count after skip(10) : 25" is incorrect - this needs to be in the 40..50 range, doesn't it? > > Now I understand that the Java Doc is saying skip/limit 'at most n elements' but IMHO this is not particular useful. > > skip/limit _could_ consume more than n elements of a source stream (and calling the filter predicate in my example more often in the parallel than serial case) but should do "exactly n" when passing elements to further steps in the processing downstreams. > > Regards > Christian > From forax at univ-mlv.fr Thu Dec 13 06:30:39 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 13 Dec 2012 15:30:39 +0100 Subject: Stream perf test In-Reply-To: <6AA74569-9E4B-4455-B7E4-E79B3A61B533@oracle.com> References: <50C99F48.4030709@univ-mlv.fr> <6AA74569-9E4B-4455-B7E4-E79B3A61B533@oracle.com> Message-ID: <50C9E68F.6080304@univ-mlv.fr> On 12/13/2012 10:59 AM, Aleksey Shipilev wrote: > Hi Remi, > > We do have lots of perf tests internally (due to legal at this point to open source them), and yes, these are tricky to get right. There seem to be nothing special about the streams per se, just usual micro benchmarking troubles. If you can send your tests along, we can figure whether you are dealing with something we already know about. > > -Aleksey. My main issue is that depending on the context the OSR is triggered before or after the method compilation resulting is code that are very different. Anyway, when the other part of my code will be stabilized I will publish it so you can take a look. R?mi > > On 13.12.2012, at 13:26, Remi Forax wrote: > >> I've tried to write several tests that use the stream pipeline and I've >> troubled to get stable values, sometimes the fastest time is one order >> magnitude faster than the slowest time. >> Do we have any perf tests written somewhere to see what I did wrong ? >> >> R?mi >> From paul.sandoz at oracle.com Thu Dec 13 06:38:35 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 13 Dec 2012 15:38:35 +0100 Subject: skip/limit in parallel context In-Reply-To: <50C9E262.5000308@univ-mlv.fr> References: <8C2D1D75-C92B-4171-A16D-7BFD81F67F23@oracle.com> <50C9E262.5000308@univ-mlv.fr> Message-ID: <965D661E-0ED0-4CB2-B9D8-253BAE6C0B59@oracle.com> On Dec 13, 2012, at 3:12 PM, Remi Forax wrote: > > the main issue here is that, with a sequential stream, you can write > > .reduce(0L, (count, t) -> count + 1L, null) > Yeah, thats a bug, should throw an NPE. Paul. From paul.sandoz at oracle.com Thu Dec 13 06:52:16 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 13 Dec 2012 15:52:16 +0100 Subject: skip/limit in parallel context In-Reply-To: References: <8C2D1D75-C92B-4171-A16D-7BFD81F67F23@oracle.com> Message-ID: <537031C2-1BE7-4B59-B3EB-5530D3D51606@oracle.com> On Dec 13, 2012, at 3:20 PM, "Mallwitz, Christian" wrote: > Hi Paul, > > Ah, this helps and it even produces the expected result :-) > > Your explaination though gets me confused when looking at the javadoc: On java.util.stream.Stream: > > U reduce(U base, Combiner reducer, BinaryOperator combiner) > > the reducer (2. param) is a Combiner and the combiner (3. param) is the BinaryOperator ??? > I know :-) in the latest source Combiner was replaced with BiFunction: U reduce(U base, BiFunction reducer, BinaryOperator combiner); > I would have at least expect my BinaryOperator '(left, right) -> left + 1L ' from the sequential operation to go to the 3rd parameter. > Note that we are currently hashing out a major improvement to this area so stay tuned. > > Additionally, I would assume calling "reduce(T base, BinaryOperator op)" on a parallel stream would never make sense, would it? It can for a commutative function such as sum, or finding the min or max value. > Vice versa: calling "reduce(U base, Combiner reducer, BinaryOperator combiner)" should be reserved for parallel streams as there is no 'combining' on a serial stream? > I would not be inclined to restrict it use for parallel evaluation only and requiring developers to do "if (s.isParallel())". When using reduce (or fold) one is obligated to consider certain properties of the function. We need to make that obligation easier to understand. Paul. From brian.goetz at oracle.com Thu Dec 13 08:28:57 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 13 Dec 2012 11:28:57 -0500 Subject: skip/limit in parallel context In-Reply-To: <8C2D1D75-C92B-4171-A16D-7BFD81F67F23@oracle.com> References: <8C2D1D75-C92B-4171-A16D-7BFD81F67F23@oracle.com> Message-ID: <50CA0249.30402@oracle.com> Alternately: .map(e -> 1).reduce(0, Integer::sum) On 12/13/2012 7:13 AM, Paul Sandoz wrote: > Hi Christian, > > The problem is you are not combining/merging the counts correctly. The reduction step is different to the combining/merging step. > > Try this: > > .reduce(0L, (count, t) -> count + 1L, (countLeft, countRight) -> countLeft + countRight) > > The first lambda is the reducer, this will be executed on leaf nodes of the computation tree (a sequential stream can be considered a degenerate case of just one leaf node). The second lambda will be executed to combine the results of two nodes. > > This is a tricky area, it's not entirely a free lunch going from sequential to parallel evaluation with folding or reducing. You need to be aware of the properties of your reducing function (e.g. is it associative or commutative?, are the combining and reducing steps different?, what is the identity element?). > > Hth, > Paul. > > On Dec 13, 2012, at 12:30 PM, "Mallwitz, Christian" wrote: > >> Hi, >> >> Using jdk1.8.0-b68-09_dec_2012 and having (this is counting even numbers up to 100 in various ways) >> >> import java.util.Arrays; >> import java.util.stream.Stream; >> >> public class LambdaParallelLimitSkip { >> >> private static final int n = 100; >> >> public static void main(String[] args) { >> testSerial(); >> testParallel(); >> } >> >> public static void testSerial() { >> System.out.println("serial count after limit(10): " + getArrayBasedStream(false) >> .filter(l -> l%2==0) // filter even numbers >> .limit(10) >> .reduce(0L, (left, right) -> left + 1L)); // count >> System.out.println("serial count after skip(10) : " + getArrayBasedStream(false) >> .filter(l -> l%2==0) // filter even numbers >> .skip(10) >> .reduce(0L, (left, right) -> left + 1L)); // count >> } >> >> public static void testParallel() { >> System.out.println("parallel count after limit(10): " + getArrayBasedStream(true) >> .filter(l -> l%2==0) // filter even numbers >> .limit(10) >> .reduce(0L, (left, right) -> left + 1L)); // count >> System.out.println("parallel count after skip(10) : " + getArrayBasedStream(true) >> .filter(l -> l%2==0) // filter even numbers >> .skip(10) >> .reduce(0L, (left, right) -> left + 1L)); // count >> } >> >> public static Stream getArrayBasedStream(boolean parallel) { >> Long[] list = new Long[n]; >> for(int i=0; i> return parallel ? Arrays.asList(list).parallel() : Arrays.asList(list).stream(); >> } >> } >> >> This outputs >> >> serial count after limit(10): 10 >> serial count after skip(10) : 40 >> parallel count after limit(10): 7 >> parallel count after skip(10) : 25 >> >> The last item "parallel count after skip(10) : 25" is incorrect - this needs to be in the 40..50 range, doesn't it? >> >> Now I understand that the Java Doc is saying skip/limit 'at most n elements' but IMHO this is not particular useful. >> >> skip/limit _could_ consume more than n elements of a source stream (and calling the filter predicate in my example more often in the parallel than serial case) but should do "exactly n" when passing elements to further steps in the processing downstreams. >> >> Regards >> Christian >> > > From forax at univ-mlv.fr Thu Dec 13 09:31:52 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 13 Dec 2012 18:31:52 +0100 Subject: skip/limit in parallel context In-Reply-To: <965D661E-0ED0-4CB2-B9D8-253BAE6C0B59@oracle.com> References: <8C2D1D75-C92B-4171-A16D-7BFD81F67F23@oracle.com> <50C9E262.5000308@univ-mlv.fr> <965D661E-0ED0-4CB2-B9D8-253BAE6C0B59@oracle.com> Message-ID: <50CA1108.8060609@univ-mlv.fr> On 12/13/2012 03:38 PM, Paul Sandoz wrote: > On Dec 13, 2012, at 3:12 PM, Remi Forax wrote: >> the main issue here is that, with a sequential stream, you can write >> >> .reduce(0L, (count, t) -> count + 1L, null) >> > Yeah, thats a bug, should throw an NPE. My point was more that the last parameter is not used at all with a sequential stream .reduce(0L, (count, t) -> count + 1L, Something::stupid) will work too. > > Paul. > R?mi From henry.jen at oracle.com Thu Dec 13 11:14:23 2012 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 13 Dec 2012 11:14:23 -0800 Subject: Feedback on the implementation of StringJoiner In-Reply-To: References: <50B8D792.9060601@oracle.com> Message-ID: <50CA290F.4010402@oracle.com> On 12/12/2012 12:39 PM, Roel Spilker wrote: > And subSequence could do a slightly better jo > > if (start < value.length()) { > return new StringBuilder(value.subSequence(start, value.length())) > .append(suffix.subSequence(0, end - value.length())) > .toString(); > > > is IMHO less performant than: > > if (start < value.length()) { > return new StringBuilder(end - start) > > .append(value.subSequence(start, value.length())) > > .append(suffix.subSequence(0, end - value.length())) .toString(); > > Agree. Anyway, the implementation no longer implement CharSequence, thus more code removed. > > On Wed, Dec 12, 2012 at 9:34 PM, Roel Spilker wrote: > >> Oh, and please remove the string concatenation from the constructor. Since >> prefix and suffix are stored separately and setEmptyOutput does not accept >> null values, a null-check on the field can be used to calculate the >> emptyOutput when it is needed. I think the common case is that the >> emptyOutput value is not read at all. I don't see much gain here, it make sense to me to have a proper initial value and it's not likely to be a bottleneck for performance or memory print. We do keep length() API just in case someone would like to know before actually convert to string. Have a proper value for emptyOutput helps not to duplicate code. We can extract the logic to an internal private method, that would be an overhead for each call. >> >> >> On Wed, Dec 12, 2012 at 9:27 PM, Roel Spilker wrote: >> >>> Well, a lot of code was removed, what is in my opinion always a good >>> thing. >>> >>> Apart from the comments already mentioned, I have one other point. The >>> JavaDoc of length(), charAt(int) and subSequence(int, int) still define >>> their behavior as being equivalent to the same operation on the toString() >>> result. However, the class isn't final. I don't think it is a promise that >>> should be made, because it puts quite a burden on a subclass. My preferred >>> solution would be to make the class final. However, I don't know if that is >>> an option. I believe it is reasonable to have contract state the expect value, which is proper value based on the string representation at the moment. You have a good point whether we should mention toString(), as the contract specified that toString() should return the string representation of the value, they are equivalent. Cheers, Henry From henry.jen at oracle.com Thu Dec 13 11:18:06 2012 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 13 Dec 2012 11:18:06 -0800 Subject: Feedback on the implementation of StringJoiner In-Reply-To: <50C9A1E8.4020908@univ-mlv.fr> References: <50B8D792.9060601@oracle.com> <50C67FD6.2040808@univ-mlv.fr> <50C69761.8050400@oracle.com> <50C6E9E3.4000506@univ-mlv.fr> <50C9A1E8.4020908@univ-mlv.fr> Message-ID: <50CA29EE.7070006@oracle.com> On 12/13/2012 01:37 AM, Remi Forax wrote: > Hi Henry, > if we don't change the implementation of StringJoiner now (see my mail > about my inability to test the stream pipeline), > there are at least two things that can be changed in your current > implementation. > We don't change as I explained to you, save an intermediate allocate of char[] and two copies for a list and copy of references is not necessary better. > All the static final String can be removed because the string are > interned so there is no need to store then in a static fields. > Even if you think the code is more clear with that and you may be right, > it's not a standard practice, the only code that does that is > String.java (as far as I know). > > You don't need the field 'somethingAdded' because you can test the > length of the StringBuilder (value). > Agree. Cheers, Henry From leonid.arbouzov at oracle.com Thu Dec 13 11:24:08 2012 From: leonid.arbouzov at oracle.com (Leonid Arbouzov) Date: Thu, 13 Dec 2012 11:24:08 -0800 Subject: signatures that are recorded for default methods In-Reply-To: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> Message-ID: <50CA2B58.5030103@oracle.com> Hello Lance, My understanding would be that the signature test should check that interface method is marked as default method but do not track the code in its default body (assuming that the body is not a part of a spec - API javadoc). (I've confirmed that with the signature test developer) Thanks, -leonid On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: > Folks, > > Will the signatures for interfaces that are recorded by the TCKs for interfaces record the fact that a method includes a default method? or will it just record the method definition? > > I am assuming it will, but I know there has been discussion that a implementor could choose a different default implementation on one of the recent threads that was up for review. > > I am still trying to understand what our guidelines are, if any for documenting the behavior of the supplied default methods given the javadocs are part of the specification for many APIs (and in some case the only spec). > > Best > Lance > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > From joe.darcy at oracle.com Thu Dec 13 13:05:36 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 13 Dec 2012 13:05:36 -0800 Subject: signatures that are recorded for default methods In-Reply-To: <50CA2B58.5030103@oracle.com> References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> Message-ID: <50CA4320.40408@oracle.com> Hello, As with concrete methods on abstract classes, I would expect the specifications of the default methods to often contain text akin to "This default implementation does x, y, and z" since if the method is to be called by subtypes, the self-use patterns in the default method need to be known. Cheers, -Joe On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: > Hello Lance, > > My understanding would be that the signature test > should check that interface method is marked as default method > but do not track the code in its default body > (assuming that the body is not a part of a spec - API javadoc). > > (I've confirmed that with the signature test developer) > > Thanks, > -leonid > > On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: >> Folks, >> >> Will the signatures for interfaces that are recorded by the TCKs for interfaces record the fact that a method includes a default method? or will it just record the method definition? >> >> I am assuming it will, but I know there has been discussion that a implementor could choose a different default implementation on one of the recent threads that was up for review. >> >> I am still trying to understand what our guidelines are, if any for documenting the behavior of the supplied default methods given the javadocs are part of the specification for many APIs (and in some case the only spec). >> >> Best >> Lance >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> > From Lance.Andersen at oracle.com Thu Dec 13 13:17:39 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 13 Dec 2012 16:17:39 -0500 Subject: signatures that are recorded for default methods In-Reply-To: <50CA4320.40408@oracle.com> References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> <50CA4320.40408@oracle.com> Message-ID: <2120CD2B-1918-4527-91F0-F37FFA38C247@oracle.com> Hi Joe, I would agree but if the default implementation is not considered part of the spec, should it be defined in the javadoc and if so, IMHO a javadoc tag would be very useful so that we are consistent in at least presentation. Leonid, thank you for the confirmation. Best Lance On Dec 13, 2012, at 4:05 PM, Joe Darcy wrote: > Hello, > > As with concrete methods on abstract classes, I would expect the specifications of the default methods to often contain text akin to "This default implementation does x, y, and z" since if the method is to be called by subtypes, the self-use patterns in the default method need to be known. > > Cheers, > > -Joe > > On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: >> Hello Lance, >> >> My understanding would be that the signature test >> should check that interface method is marked as default method >> but do not track the code in its default body >> (assuming that the body is not a part of a spec - API javadoc). >> >> (I've confirmed that with the signature test developer) >> >> Thanks, >> -leonid >> >> On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: >>> Folks, >>> >>> Will the signatures for interfaces that are recorded by the TCKs for interfaces record the fact that a method includes a default method? or will it just record the method definition? >>> >>> I am assuming it will, but I know there has been discussion that a implementor could choose a different default implementation on one of the recent threads that was up for review. >>> >>> I am still trying to understand what our guidelines are, if any for documenting the behavior of the supplied default methods given the javadocs are part of the specification for many APIs (and in some case the only spec). >>> >>> Best >>> Lance >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >> > -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From leonid.arbouzov at oracle.com Thu Dec 13 15:16:42 2012 From: leonid.arbouzov at oracle.com (Leonid Arbuzov) Date: Thu, 13 Dec 2012 15:16:42 -0800 Subject: signatures that are recorded for default methods In-Reply-To: <50CA4320.40408@oracle.com> References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> <50CA4320.40408@oracle.com> Message-ID: <50CA61DA.7050205@oracle.com> Good point, Joe. Those extra assertions for default methods can be checked by regular API tests separately from signature tests. Thanks, -leonid On 12/13/2012 1:05 PM, Joe Darcy wrote: > Hello, > > As with concrete methods on abstract classes, I would expect the > specifications of the default methods to often contain text akin to > "This default implementation does x, y, and z" since if the method is > to be called by subtypes, the self-use patterns in the default method > need to be known. > > Cheers, > > -Joe > > On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: >> Hello Lance, >> >> My understanding would be that the signature test >> should check that interface method is marked as default method >> but do not track the code in its default body >> (assuming that the body is not a part of a spec - API javadoc). >> >> (I've confirmed that with the signature test developer) >> >> Thanks, >> -leonid >> >> On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: >>> Folks, >>> >>> Will the signatures for interfaces that are recorded by the TCKs for >>> interfaces record the fact that a method includes a default method? >>> or will it just record the method definition? >>> >>> I am assuming it will, but I know there has been discussion that a >>> implementor could choose a different default implementation on one >>> of the recent threads that was up for review. >>> >>> I am still trying to understand what our guidelines are, if any for >>> documenting the behavior of the supplied default methods given the >>> javadocs are part of the specification for many APIs (and in some >>> case the only spec). >>> >>> Best >>> Lance >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >> > From Lance.Andersen at oracle.com Thu Dec 13 15:30:32 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 13 Dec 2012 18:30:32 -0500 Subject: signatures that are recorded for default methods In-Reply-To: <50CA61DA.7050205@oracle.com> References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> <50CA4320.40408@oracle.com> <50CA61DA.7050205@oracle.com> Message-ID: <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> On Dec 13, 2012, at 6:16 PM, Leonid Arbuzov wrote: > Good point, Joe. > Those extra assertions for default methods can be checked > by regular API tests separately from signature tests. I am not clear on this. See the message attached from David which ask a similar question (from the attached email): ------------------- 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. ------------------- If everyone needs to implement the same default implementation then great the JCK/TCK can test it and IMHO we should have a javadoc tag for this. If everyone is free to choose what the default behavior is, then we cannot test it. So has there been a decision WRT the requirements for default methods? Best Lance > Thanks, > -leonid > > On 12/13/2012 1:05 PM, Joe Darcy wrote: >> Hello, >> >> As with concrete methods on abstract classes, I would expect the specifications of the default methods to often contain text akin to "This default implementation does x, y, and z" since if the method is to be called by subtypes, the self-use patterns in the default method need to be known. >> >> Cheers, >> >> -Joe >> >> On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: >>> Hello Lance, >>> >>> My understanding would be that the signature test >>> should check that interface method is marked as default method >>> but do not track the code in its default body >>> (assuming that the body is not a part of a spec - API javadoc). >>> >>> (I've confirmed that with the signature test developer) >>> >>> Thanks, >>> -leonid >>> >>> On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: >>>> Folks, >>>> >>>> Will the signatures for interfaces that are recorded by the TCKs for interfaces record the fact that a method includes a default method? or will it just record the method definition? >>>> >>>> I am assuming it will, but I know there has been discussion that a implementor could choose a different default implementation on one of the recent threads that was up for review. >>>> >>>> I am still trying to understand what our guidelines are, if any for documenting the behavior of the supplied default methods given the javadocs are part of the specification for many APIs (and in some case the only spec). >>>> >>>> Best >>>> Lance >>>> >>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >>>> >>> >> -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An embedded message was scrubbed... From: David Holmes Subject: Re: Request for Review : CR#8004015 : Add interface extends and defaults for basic functional interfaces Date: Thu, 29 Nov 2012 15:50:57 +1000 Size: 8211 Url: http://mail.openjdk.java.net/pipermail/lambda-dev/attachments/20121213/301ad175/Addinterfaceextendsanddefaultsforbasicfunctionalinterfaces.eml From mike.duigou at oracle.com Thu Dec 13 15:31:39 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 13 Dec 2012 23:31:39 +0000 Subject: hg: lambda/lambda/jdk: additional javadocs and checks in Iterator Message-ID: <20121213233151.280FB47126@hg.openjdk.java.net> Changeset: e993e3e89c78 Author: akhil Date: 2012-12-13 15:26 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e993e3e89c78 additional javadocs and checks in Iterator Better forEach for SmallSet Tests for Iterator extension methods ! src/share/classes/java/util/Iterator.java ! src/share/classes/jdk/internal/org/objectweb/asm/tree/analysis/SmallSet.java + test/java/util/IteratorExtensionMethodsTest.java From jonathan.gibbons at oracle.com Thu Dec 13 15:36:24 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 13 Dec 2012 15:36:24 -0800 Subject: signatures that are recorded for default methods In-Reply-To: <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> <50CA4320.40408@oracle.com> <50CA61DA.7050205@oracle.com> <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> Message-ID: <50CA6678.8010909@oracle.com> On 12/13/2012 03:30 PM, Lance Andersen - Oracle wrote: > If everyone needs to implement the same default implementation then great the JCK/TCK can test it and IMHO we should have a javadoc tag for this. A javadoc tag is an implementation detail that does not, of itself, show up in the generated documentation. It should be enough to use standard terms like "must", "may", "this implementation" to make it clear what is normative text and what is non-normative text. From mike.duigou at oracle.com Thu Dec 13 15:40:25 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 13 Dec 2012 23:40:25 +0000 Subject: hg: lambda/lambda/jdk: javadoc improvements and cleanups Message-ID: <20121213234037.7786847128@hg.openjdk.java.net> Changeset: 574c6e8bdb48 Author: henryjen Date: 2012-12-13 15:34 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/574c6e8bdb48 javadoc improvements and cleanups fix test license ! src/share/classes/java/util/Comparator.java ! test/java/util/ComparatorsTest.java From leonid.arbouzov at oracle.com Thu Dec 13 15:41:24 2012 From: leonid.arbouzov at oracle.com (Leonid Arbuzov) Date: Thu, 13 Dec 2012 15:41:24 -0800 Subject: signatures that are recorded for default methods In-Reply-To: <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> <50CA4320.40408@oracle.com> <50CA61DA.7050205@oracle.com> <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> Message-ID: <50CA67A4.2040608@oracle.com> If those extra statements are normative they can be checked by conformance tests, if not normative, those can be checked by implementation-specific unit tests. Specification should be clear what is normative and what is not. Tagging normative requirements in API specs (and in other specs too!) would be certainly helpful. Thanks, -leonid On 12/13/2012 3:30 PM, Lance Andersen - Oracle wrote: > On Dec 13, 2012, at 6:16 PM, Leonid Arbuzov wrote: > >> Good point, Joe. >> Those extra assertions for default methods can be checked >> by regular API tests separately from signature tests. > I am not clear on this. See the message attached from David which ask a similar question (from the attached email): > ------------------- > 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. > ------------------- > > > If everyone needs to implement the same default implementation then great the JCK/TCK can test it and IMHO we should have a javadoc tag for this. > > If everyone is free to choose what the default behavior is, then we cannot test it. > > So has there been a decision WRT the requirements for default methods? > > > Best > Lance >> Thanks, >> -leonid >> >> On 12/13/2012 1:05 PM, Joe Darcy wrote: >>> Hello, >>> >>> As with concrete methods on abstract classes, I would expect the specifications of the default methods to often contain text akin to "This default implementation does x, y, and z" since if the method is to be called by subtypes, the self-use patterns in the default method need to be known. >>> >>> Cheers, >>> >>> -Joe >>> >>> On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: >>>> Hello Lance, >>>> >>>> My understanding would be that the signature test >>>> should check that interface method is marked as default method >>>> but do not track the code in its default body >>>> (assuming that the body is not a part of a spec - API javadoc). >>>> >>>> (I've confirmed that with the signature test developer) >>>> >>>> Thanks, >>>> -leonid >>>> >>>> On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: >>>>> Folks, >>>>> >>>>> Will the signatures for interfaces that are recorded by the TCKs for interfaces record the fact that a method includes a default method? or will it just record the method definition? >>>>> >>>>> I am assuming it will, but I know there has been discussion that a implementor could choose a different default implementation on one of the recent threads that was up for review. >>>>> >>>>> I am still trying to understand what our guidelines are, if any for documenting the behavior of the supplied default methods given the javadocs are part of the specification for many APIs (and in some case the only spec). >>>>> >>>>> Best >>>>> Lance >>>>> >>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>> Oracle Java Engineering >>>>> 1 Network Drive >>>>> Burlington, MA 01803 >>>>> Lance.Andersen at oracle.com >>>>> >>>>> > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com From pbenedict at apache.org Thu Dec 13 15:46:27 2012 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 13 Dec 2012 17:46:27 -0600 Subject: signatures that are recorded for default methods In-Reply-To: <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> <50CA4320.40408@oracle.com> <50CA61DA.7050205@oracle.com> <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> Message-ID: Lance, Good questions. Someone with authority will surely answer, but here's my armchair opinion... If the Javadoc is to specify how the default method executes, than that would naturally infer all default implementations must have a stated contract. You can't document the default execution behavior in the public API and then let a provider switch the behavior. The two go hand-in-hand, imo. Paul On Thu, Dec 13, 2012 at 5:30 PM, Lance Andersen - Oracle wrote: > > On Dec 13, 2012, at 6:16 PM, Leonid Arbuzov wrote: > >> Good point, Joe. >> Those extra assertions for default methods can be checked >> by regular API tests separately from signature tests. > > I am not clear on this. See the message attached from David which ask a similar question (from the attached email): > ------------------- > 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. > ------------------- > > > If everyone needs to implement the same default implementation then great the JCK/TCK can test it and IMHO we should have a javadoc tag for this. > > If everyone is free to choose what the default behavior is, then we cannot test it. > > So has there been a decision WRT the requirements for default methods? > > > Best > Lance >> Thanks, >> -leonid >> >> On 12/13/2012 1:05 PM, Joe Darcy wrote: >>> Hello, >>> >>> As with concrete methods on abstract classes, I would expect the specifications of the default methods to often contain text akin to "This default implementation does x, y, and z" since if the method is to be called by subtypes, the self-use patterns in the default method need to be known. >>> >>> Cheers, >>> >>> -Joe >>> >>> On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: >>>> Hello Lance, >>>> >>>> My understanding would be that the signature test >>>> should check that interface method is marked as default method >>>> but do not track the code in its default body >>>> (assuming that the body is not a part of a spec - API javadoc). >>>> >>>> (I've confirmed that with the signature test developer) >>>> >>>> Thanks, >>>> -leonid >>>> >>>> On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: >>>>> Folks, >>>>> >>>>> Will the signatures for interfaces that are recorded by the TCKs for interfaces record the fact that a method includes a default method? or will it just record the method definition? >>>>> >>>>> I am assuming it will, but I know there has been discussion that a implementor could choose a different default implementation on one of the recent threads that was up for review. >>>>> >>>>> I am still trying to understand what our guidelines are, if any for documenting the behavior of the supplied default methods given the javadocs are part of the specification for many APIs (and in some case the only spec). >>>>> >>>>> Best >>>>> Lance >>>>> >>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>> Oracle Java Engineering >>>>> 1 Network Drive >>>>> Burlington, MA 01803 >>>>> Lance.Andersen at oracle.com >>>>> >>>>> >>>> >>> > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From mike.duigou at oracle.com Thu Dec 13 15:52:54 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 13 Dec 2012 23:52:54 +0000 Subject: hg: lambda/lambda/jdk: Renovations on StringJoiner Message-ID: <20121213235306.24DBB47129@hg.openjdk.java.net> Changeset: 6fb8cefc938c Author: henryjen Date: 2012-12-13 15:52 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6fb8cefc938c Renovations on StringJoiner ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java ! src/share/classes/java/util/StringJoiner.java ! test-ng/tests/org/openjdk/tests/java/lang/StringTest.java ! test-ng/tests/org/openjdk/tests/java/util/StringJoinerTest.java From akhil.arora at oracle.com Thu Dec 13 17:24:35 2012 From: akhil.arora at oracle.com (Akhil Arora) Date: Thu, 13 Dec 2012 17:24:35 -0800 Subject: RFR: 8005051: default methods for Iterator Message-ID: <50CA7FD3.5020701@oracle.com> As part of the library lambdafication, this patch adds a forEach default method to Iterator, and converts remove() into a default method so that implementations of Iterator no longer have to override remove if they desire the default behavior, which is to throw an UnsupportedOperationException. http://cr.openjdk.java.net/~akhil/8005051.0/webrev/ The above patch requires a small patch to an internal class which happens to implement both Iterable and Iterator. Now both Iterable and Iterator supply a default forEach method, so the compiler balks. One minimally intrusive solution is for this class to override both defaults and provide its own version of forEach. http://cr.openjdk.java.net/~akhil/8005053.0/webrev/ Please review Thanks From mike.duigou at oracle.com Thu Dec 13 21:24:30 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 13 Dec 2012 21:24:30 -0800 Subject: RFR : CR8004015 : Add parent interfaces and default methods to basic functional interfaces Message-ID: <99DC2763-ED44-42CA-90F3-04AD07B2846D@oracle.com> Hello all; I have updated the webrev again for hopefully the last time: http://cr.openjdk.java.net/~mduigou/8004015/3/webrev/ http://cr.openjdk.java.net/~mduigou/8004015/3/specdiff/overview-summary.html The implementation now uses Primitive.primitiveValue() ie. Integer.integerValue() rather than a cast. Same bytecode but using the intrinsic function makes it more clear that result is either primitive or NPE and that CCE is not possible. I have added @throws NPE for a number of the default methods. We won't be including @throws NPE in all cases where null is disallowed because when the @throws NPE is declared the API is required to throw NPE in that circumstance. So for cases where the NPE is "naturally" thrown or that aren't performance sensitive we will likely add @throws NPE declarations but for performance sensitive methods we won't be adding explicit null checks to match a @throws NPE specification. There's a tradeoff here in some cases. Please feel free to quibble about specific cases as they occur. :-) Mike From david.holmes at oracle.com Thu Dec 13 22:18:06 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Dec 2012 16:18:06 +1000 Subject: signatures that are recorded for default methods In-Reply-To: <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> <50CA4320.40408@oracle.com> <50CA61DA.7050205@oracle.com> <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> Message-ID: <50CAC49E.2010904@oracle.com> As a case in point Akhil just asked for this to be reviewed: http://cr.openjdk.java.net/~akhil/8005051.0/webrev/src/share/classes/java/util/Iterator.java.frames.html and there is no mention that the remove() implementation actually throws the exception, nor how forEach does its work. David On 14/12/2012 9:30 AM, Lance Andersen - Oracle wrote: > > On Dec 13, 2012, at 6:16 PM, Leonid Arbuzov wrote: > >> Good point, Joe. >> Those extra assertions for default methods can be checked >> by regular API tests separately from signature tests. > > I am not clear on this. See the message attached from David which ask a similar question (from the attached email): > ------------------- > 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. > ------------------- > > > If everyone needs to implement the same default implementation then great the JCK/TCK can test it and IMHO we should have a javadoc tag for this. > > If everyone is free to choose what the default behavior is, then we cannot test it. > > So has there been a decision WRT the requirements for default methods? > > > Best > Lance >> Thanks, >> -leonid >> >> On 12/13/2012 1:05 PM, Joe Darcy wrote: >>> Hello, >>> >>> As with concrete methods on abstract classes, I would expect the specifications of the default methods to often contain text akin to "This default implementation does x, y, and z" since if the method is to be called by subtypes, the self-use patterns in the default method need to be known. >>> >>> Cheers, >>> >>> -Joe >>> >>> On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: >>>> Hello Lance, >>>> >>>> My understanding would be that the signature test >>>> should check that interface method is marked as default method >>>> but do not track the code in its default body >>>> (assuming that the body is not a part of a spec - API javadoc). >>>> >>>> (I've confirmed that with the signature test developer) >>>> >>>> Thanks, >>>> -leonid >>>> >>>> On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: >>>>> Folks, >>>>> >>>>> Will the signatures for interfaces that are recorded by the TCKs for interfaces record the fact that a method includes a default method? or will it just record the method definition? >>>>> >>>>> I am assuming it will, but I know there has been discussion that a implementor could choose a different default implementation on one of the recent threads that was up for review. >>>>> >>>>> I am still trying to understand what our guidelines are, if any for documenting the behavior of the supplied default methods given the javadocs are part of the specification for many APIs (and in some case the only spec). >>>>> >>>>> Best >>>>> Lance >>>>> >>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>> Oracle Java Engineering >>>>> 1 Network Drive >>>>> Burlington, MA 01803 >>>>> Lance.Andersen at oracle.com >>>>> >>>>> >>>> >>> > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > From david.holmes at oracle.com Thu Dec 13 22:21:14 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Dec 2012 16:21:14 +1000 Subject: signatures that are recorded for default methods In-Reply-To: References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> <50CA4320.40408@oracle.com> <50CA61DA.7050205@oracle.com> <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> Message-ID: <50CAC55A.3010602@oracle.com> Paul, On 14/12/2012 9:46 AM, Paul Benedict wrote: > Lance, > > Good questions. Someone with authority will surely answer, but here's > my armchair opinion... > > If the Javadoc is to specify how the default method executes, than > that would naturally infer all default implementations must have a > stated contract. You can't document the default execution behavior in > the public API and then let a provider switch the behavior. The two go > hand-in-hand, imo. I couldn't really make sense of that. :) The method has a contract. The "default implementation" has to honor that contract. The question is whether how the "default implementation" honors the method contract is required to be part of a second contract. I hope that made sense :) David ----- > Paul > > On Thu, Dec 13, 2012 at 5:30 PM, Lance Andersen - Oracle > wrote: >> >> On Dec 13, 2012, at 6:16 PM, Leonid Arbuzov wrote: >> >>> Good point, Joe. >>> Those extra assertions for default methods can be checked >>> by regular API tests separately from signature tests. >> >> I am not clear on this. See the message attached from David which ask a similar question (from the attached email): >> ------------------- >> 2. It is not obvious to me that the JDK's choice for a default implementation has to be _the_ only possible implementation choice. In many/most cases there will be a very obvious choice, but that doesn't mean that all suppliers of OpenJDK classes have to be locked in to that choice. >> ------------------- >> >> >> If everyone needs to implement the same default implementation then great the JCK/TCK can test it and IMHO we should have a javadoc tag for this. >> >> If everyone is free to choose what the default behavior is, then we cannot test it. >> >> So has there been a decision WRT the requirements for default methods? >> >> >> Best >> Lance >>> Thanks, >>> -leonid >>> >>> On 12/13/2012 1:05 PM, Joe Darcy wrote: >>>> Hello, >>>> >>>> As with concrete methods on abstract classes, I would expect the specifications of the default methods to often contain text akin to "This default implementation does x, y, and z" since if the method is to be called by subtypes, the self-use patterns in the default method need to be known. >>>> >>>> Cheers, >>>> >>>> -Joe >>>> >>>> On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: >>>>> Hello Lance, >>>>> >>>>> My understanding would be that the signature test >>>>> should check that interface method is marked as default method >>>>> but do not track the code in its default body >>>>> (assuming that the body is not a part of a spec - API javadoc). >>>>> >>>>> (I've confirmed that with the signature test developer) >>>>> >>>>> Thanks, >>>>> -leonid >>>>> >>>>> On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: >>>>>> Folks, >>>>>> >>>>>> Will the signatures for interfaces that are recorded by the TCKs for interfaces record the fact that a method includes a default method? or will it just record the method definition? >>>>>> >>>>>> I am assuming it will, but I know there has been discussion that a implementor could choose a different default implementation on one of the recent threads that was up for review. >>>>>> >>>>>> I am still trying to understand what our guidelines are, if any for documenting the behavior of the supplied default methods given the javadocs are part of the specification for many APIs (and in some case the only spec). >>>>>> >>>>>> Best >>>>>> Lance >>>>>> >>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>>> Oracle Java Engineering >>>>>> 1 Network Drive >>>>>> Burlington, MA 01803 >>>>>> Lance.Andersen at oracle.com >>>>>> >>>>>> >>>>> >>>> >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > From julianhyde at gmail.com Thu Dec 13 22:23:20 2012 From: julianhyde at gmail.com (Julian Hyde) Date: Thu, 13 Dec 2012 22:23:20 -0800 Subject: Request for binary search using functions In-Reply-To: <50C85332.3060107@gmail.com> References: <50C85332.3060107@gmail.com> Message-ID: <03428E0B-058A-4B21-8297-4463E17BAF8D@gmail.com> On Dec 12, 2012, at 1:49 AM, Peter Levart wrote: > Like that? Almost what I was after, but not quite. I was looking for something that could implement any kind of abstract list, not just one based on an array. The problem is that AbstractList has two abstract functions, and a lambda only has one. But I find that whenever I create an AbstractList its size is fixed at create time, and this is true here also. So, let's define a library method that takes a size and a gettable and returns a list: interface Gettable { T get(int i); } private static abstract class RandomAccessAbstractList extends AbstractList implements RandomAccess {} public static List list(final int size, final Gettable gettable) { return new RandomAccessAbstractList() { public T get(int index) { return gettable.get(index); } public int size() { return size; } }; } Assuming that the list() method is part of a standard library (anyone on this list feel like adding it?!), the binary search problem can now be solved in one line: SimpleDateFormat[] array; String seek; return Collections.binarySearch(list(array.length, (i) -> array[i].toPattern()), seek); Julian From david.holmes at oracle.com Thu Dec 13 22:28:41 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Dec 2012 16:28:41 +1000 Subject: RFR : CR8004015 : Add parent interfaces and default methods to basic functional interfaces In-Reply-To: <99DC2763-ED44-42CA-90F3-04AD07B2846D@oracle.com> References: <99DC2763-ED44-42CA-90F3-04AD07B2846D@oracle.com> Message-ID: <50CAC719.7090308@oracle.com> HI Mike, On 14/12/2012 3:24 PM, Mike Duigou wrote: > Hello all; > > I have updated the webrev again for hopefully the last time: > > http://cr.openjdk.java.net/~mduigou/8004015/3/webrev/ > http://cr.openjdk.java.net/~mduigou/8004015/3/specdiff/overview-summary.html > > The implementation now uses Primitive.primitiveValue() ie. Integer.integerValue() rather than a cast. Same bytecode but using the intrinsic function makes it more clear that result is either primitive or NPE and that CCE is not possible. > > I have added @throws NPE for a number of the default methods. We won't be including @throws NPE in all cases where null is disallowed because when the @throws NPE is declared the API is required to throw NPE in that circumstance. So for cases where the NPE is "naturally" thrown or that aren't performance sensitive we will likely add @throws NPE declarations but for performance sensitive methods we won't be adding explicit null checks to match a @throws NPE specification. There's a tradeoff here in some cases. Please feel free to quibble about specific cases as they occur. :-) That doesn't make sense to me. The throwing of the NPE is intended to be part of the specification not an implementation choice. Further @param foo non-null, is just as binding on implementations as @throws NPE if foo is null. ??? I think defining the NPE via the @param and @throws is a lose-lose situation: ! * @param left {@inheritDoc}, must be non-null ! * @param right {@inheritDoc}, must be non-null ! * @return {@inheritDoc}, always non-null ! * @throws NullPointerException if {@code left} or {@code right} is null You only need one convention. David ----- > Mike From peter.levart at gmail.com Fri Dec 14 01:06:58 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 14 Dec 2012 10:06:58 +0100 Subject: signatures that are recorded for default methods In-Reply-To: <50CAC55A.3010602@oracle.com> References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> <50CA4320.40408@oracle.com> <50CA61DA.7050205@oracle.com> <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> <50CAC55A.3010602@oracle.com> Message-ID: <50CAEC32.6060802@gmail.com> On 12/14/2012 07:21 AM, David Holmes wrote: > Paul, > > On 14/12/2012 9:46 AM, Paul Benedict wrote: >> Lance, >> >> Good questions. Someone with authority will surely answer, but here's >> my armchair opinion... >> >> If the Javadoc is to specify how the default method executes, than >> that would naturally infer all default implementations must have a >> stated contract. You can't document the default execution behavior in >> the public API and then let a provider switch the behavior. The two go >> hand-in-hand, imo. > > I couldn't really make sense of that. :) The method has a contract. > The "default implementation" has to honor that contract. The question > is whether how the "default implementation" honors the method contract > is required to be part of a second contract. > > I hope that made sense :) I think that the answer is obvious. A default method provider has only as much freedom in choosing the implementation of the default method that particular implementation differences among various providers are not observable by the "sane" usage of the API. The only soft aspect might be performance. Any other behavioural difference should not be allowed. Otherwise there will be in-compatibilities among platform providers. For example, the default Iterator.remove() is implemented in Oracle's JDK as always throwing UnsupportedOperationException. The TCK should test for that and the Javadoc should specify that. As Joe said, default interface methods are no different than any other overridable methods. They have a contract and behaviour. The behaviour can be changed (overriden) within constraints defined by contract, but the behaviour itself should also be specified and followed by different providers. Just my 2 cents. Regards, Peter > > David > ----- > > >> Paul >> >> On Thu, Dec 13, 2012 at 5:30 PM, Lance Andersen - Oracle >> wrote: >>> >>> On Dec 13, 2012, at 6:16 PM, Leonid Arbuzov wrote: >>> >>>> Good point, Joe. >>>> Those extra assertions for default methods can be checked >>>> by regular API tests separately from signature tests. >>> >>> I am not clear on this. See the message attached from David which >>> ask a similar question (from the attached email): >>> ------------------- >>> 2. It is not obvious to me that the JDK's choice for a default >>> implementation has to be _the_ only possible implementation choice. >>> In many/most cases there will be a very obvious choice, but that >>> doesn't mean that all suppliers of OpenJDK classes have to be locked >>> in to that choice. >>> ------------------- >>> >>> >>> If everyone needs to implement the same default implementation then >>> great the JCK/TCK can test it and IMHO we should have a javadoc tag >>> for this. >>> >>> If everyone is free to choose what the default behavior is, then we >>> cannot test it. >>> >>> So has there been a decision WRT the requirements for default methods? >>> >>> >>> Best >>> Lance >>>> Thanks, >>>> -leonid >>>> >>>> On 12/13/2012 1:05 PM, Joe Darcy wrote: >>>>> Hello, >>>>> >>>>> As with concrete methods on abstract classes, I would expect the >>>>> specifications of the default methods to often contain text akin >>>>> to "This default implementation does x, y, and z" since if the >>>>> method is to be called by subtypes, the self-use patterns in the >>>>> default method need to be known. >>>>> >>>>> Cheers, >>>>> >>>>> -Joe >>>>> >>>>> On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: >>>>>> Hello Lance, >>>>>> >>>>>> My understanding would be that the signature test >>>>>> should check that interface method is marked as default method >>>>>> but do not track the code in its default body >>>>>> (assuming that the body is not a part of a spec - API javadoc). >>>>>> >>>>>> (I've confirmed that with the signature test developer) >>>>>> >>>>>> Thanks, >>>>>> -leonid >>>>>> >>>>>> On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: >>>>>>> Folks, >>>>>>> >>>>>>> Will the signatures for interfaces that are recorded by the TCKs >>>>>>> for interfaces record the fact that a method includes a default >>>>>>> method? or will it just record the method definition? >>>>>>> >>>>>>> I am assuming it will, but I know there has been discussion that >>>>>>> a implementor could choose a different default implementation on >>>>>>> one of the recent threads that was up for review. >>>>>>> >>>>>>> I am still trying to understand what our guidelines are, if any >>>>>>> for documenting the behavior of the supplied default methods >>>>>>> given the javadocs are part of the specification for many APIs >>>>>>> (and in some case the only spec). >>>>>>> >>>>>>> Best >>>>>>> Lance >>>>>>> >>>>>>> Lance Andersen| Principal Member of Technical Staff | >>>>>>> +1.781.442.2037 >>>>>>> Oracle Java Engineering >>>>>>> 1 Network Drive >>>>>>> Burlington, MA 01803 >>>>>>> Lance.Andersen at oracle.com >>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> >> From r.spilker at gmail.com Fri Dec 14 01:31:34 2012 From: r.spilker at gmail.com (Roel Spilker) Date: Fri, 14 Dec 2012 10:31:34 +0100 Subject: Feedback on the implementation of StringJoiner In-Reply-To: <50CA29EE.7070006@oracle.com> References: <50B8D792.9060601@oracle.com> <50C67FD6.2040808@univ-mlv.fr> <50C69761.8050400@oracle.com> <50C6E9E3.4000506@univ-mlv.fr> <50C9A1E8.4020908@univ-mlv.fr> <50CA29EE.7070006@oracle.com> Message-ID: It is already pushed to the lambda repo: http://hg.openjdk.java.net/lambda/lambda/jdk/annotate/6fb8cefc938c/src/share/classes/java/util/StringJoiner.java I'm not sure that that's correct. If the prefix and the first added element are both empty and the infix is not, I would expect the resulting String to start with the infix, but in this implementation it starts with the first added non-empty CharSequence. So I think we still need the somethingAdded field, or need to initialize the value field with null and construct the value when the first value is added. Also, the lambda implementation still does the string concatenation in the constructor. Roel On Thu, Dec 13, 2012 at 8:18 PM, Henry Jen wrote: > On 12/13/2012 01:37 AM, Remi Forax wrote: > > Hi Henry, > > if we don't change the implementation of StringJoiner now (see my mail > > about my inability to test the stream pipeline), > > there are at least two things that can be changed in your current > > implementation. > > > > We don't change as I explained to you, save an intermediate allocate of > char[] and two copies for a list and copy of references is not necessary > better. > > > All the static final String can be removed because the string are > > interned so there is no need to store then in a static fields. > > Even if you think the code is more clear with that and you may be right, > > it's not a standard practice, the only code that does that is > > String.java (as far as I know). > > > > You don't need the field 'somethingAdded' because you can test the > > length of the StringBuilder (value). > > > > Agree. > > Cheers, > Henry > > > From r.spilker at gmail.com Fri Dec 14 01:34:47 2012 From: r.spilker at gmail.com (Roel Spilker) Date: Fri, 14 Dec 2012 10:34:47 +0100 Subject: Feedback on the implementation of StringJoiner In-Reply-To: References: <50B8D792.9060601@oracle.com> <50C67FD6.2040808@univ-mlv.fr> <50C69761.8050400@oracle.com> <50C6E9E3.4000506@univ-mlv.fr> <50C9A1E8.4020908@univ-mlv.fr> <50CA29EE.7070006@oracle.com> Message-ID: Also, the javadoc on setEmptyOutput explicitly states that the Joiner is only considered empty when the add has not been called, and not when the resulting String would be empty. This conflicts with the current immplementation of toString. The proposed null-value would fix this. Roel On Fri, Dec 14, 2012 at 10:31 AM, Roel Spilker wrote: > It is already pushed to the lambda repo: > http://hg.openjdk.java.net/lambda/lambda/jdk/annotate/6fb8cefc938c/src/share/classes/java/util/StringJoiner.java > > I'm not sure that that's correct. If the prefix and the first added > element are both empty and the infix is not, I would expect the resulting > String to start with the infix, but in this implementation it starts with > the first added non-empty CharSequence. So I think we still need the > somethingAdded field, or need to initialize the value field with null and > construct the value when the first value is added. > > Also, the lambda implementation still does the string concatenation in the > constructor. > > Roel > > > > On Thu, Dec 13, 2012 at 8:18 PM, Henry Jen wrote: > >> On 12/13/2012 01:37 AM, Remi Forax wrote: >> > Hi Henry, >> > if we don't change the implementation of StringJoiner now (see my mail >> > about my inability to test the stream pipeline), >> > there are at least two things that can be changed in your current >> > implementation. >> > >> >> We don't change as I explained to you, save an intermediate allocate of >> char[] and two copies for a list and copy of references is not necessary >> better. >> >> > All the static final String can be removed because the string are >> > interned so there is no need to store then in a static fields. >> > Even if you think the code is more clear with that and you may be right, >> > it's not a standard practice, the only code that does that is >> > String.java (as far as I know). >> > >> > You don't need the field 'somethingAdded' because you can test the >> > length of the StringBuilder (value). >> > >> >> Agree. >> >> Cheers, >> Henry >> >> >> > From peter.levart at gmail.com Fri Dec 14 01:41:40 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 14 Dec 2012 10:41:40 +0100 Subject: signatures that are recorded for default methods In-Reply-To: <50CAEC32.6060802@gmail.com> References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> <50CA4320.40408@oracle.com> <50CA61DA.7050205@oracle.com> <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> <50CAC55A.3010602@oracle.com> <50CAEC32.6060802@gmail.com> Message-ID: <50CAF454.4040309@gmail.com> On 12/14/2012 10:06 AM, Peter Levart wrote: > On 12/14/2012 07:21 AM, David Holmes wrote: >> Paul, >> >> On 14/12/2012 9:46 AM, Paul Benedict wrote: >>> Lance, >>> >>> Good questions. Someone with authority will surely answer, but here's >>> my armchair opinion... >>> >>> If the Javadoc is to specify how the default method executes, than >>> that would naturally infer all default implementations must have a >>> stated contract. You can't document the default execution behavior in >>> the public API and then let a provider switch the behavior. The two go >>> hand-in-hand, imo. >> >> I couldn't really make sense of that. :) The method has a contract. >> The "default implementation" has to honor that contract. The question >> is whether how the "default implementation" honors the method >> contract is required to be part of a second contract. >> >> I hope that made sense :) > I think that the answer is obvious. A default method provider has only > as much freedom in choosing the implementation of the default method > that particular implementation differences among various providers are > not observable by the "sane" usage of the API. The only soft aspect > might be performance. Any other behavioural difference should not be > allowed. Otherwise there will be in-compatibilities among platform > providers. > > For example, the default Iterator.remove() is implemented in Oracle's > JDK as always throwing UnsupportedOperationException. The TCK should > test for that and the Javadoc should specify that. Ok, I admit that in this particular case and other similar cases (where the default method does nothing useful), the specification could alternatively specify: "The default method behaviour is unspecified and useless. Don't call that method or make sure it is always overridden if you call it" - the TCK in that case doesn't test the behaviour of such method. Peter > > As Joe said, default interface methods are no different than any other > overridable methods. They have a contract and behaviour. The behaviour > can be changed (overriden) within constraints defined by contract, but > the behaviour itself should also be specified and followed by > different providers. > > Just my 2 cents. > > Regards, Peter > >> >> David >> ----- >> >> >>> Paul >>> >>> On Thu, Dec 13, 2012 at 5:30 PM, Lance Andersen - Oracle >>> wrote: >>>> >>>> On Dec 13, 2012, at 6:16 PM, Leonid Arbuzov wrote: >>>> >>>>> Good point, Joe. >>>>> Those extra assertions for default methods can be checked >>>>> by regular API tests separately from signature tests. >>>> >>>> I am not clear on this. See the message attached from David which >>>> ask a similar question (from the attached email): >>>> ------------------- >>>> 2. It is not obvious to me that the JDK's choice for a default >>>> implementation has to be _the_ only possible implementation choice. >>>> In many/most cases there will be a very obvious choice, but that >>>> doesn't mean that all suppliers of OpenJDK classes have to be >>>> locked in to that choice. >>>> ------------------- >>>> >>>> >>>> If everyone needs to implement the same default implementation then >>>> great the JCK/TCK can test it and IMHO we should have a javadoc tag >>>> for this. >>>> >>>> If everyone is free to choose what the default behavior is, then we >>>> cannot test it. >>>> >>>> So has there been a decision WRT the requirements for default methods? >>>> >>>> >>>> Best >>>> Lance >>>>> Thanks, >>>>> -leonid >>>>> >>>>> On 12/13/2012 1:05 PM, Joe Darcy wrote: >>>>>> Hello, >>>>>> >>>>>> As with concrete methods on abstract classes, I would expect the >>>>>> specifications of the default methods to often contain text akin >>>>>> to "This default implementation does x, y, and z" since if the >>>>>> method is to be called by subtypes, the self-use patterns in the >>>>>> default method need to be known. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> -Joe >>>>>> >>>>>> On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: >>>>>>> Hello Lance, >>>>>>> >>>>>>> My understanding would be that the signature test >>>>>>> should check that interface method is marked as default method >>>>>>> but do not track the code in its default body >>>>>>> (assuming that the body is not a part of a spec - API javadoc). >>>>>>> >>>>>>> (I've confirmed that with the signature test developer) >>>>>>> >>>>>>> Thanks, >>>>>>> -leonid >>>>>>> >>>>>>> On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: >>>>>>>> Folks, >>>>>>>> >>>>>>>> Will the signatures for interfaces that are recorded by the >>>>>>>> TCKs for interfaces record the fact that a method includes a >>>>>>>> default method? or will it just record the method definition? >>>>>>>> >>>>>>>> I am assuming it will, but I know there has been discussion >>>>>>>> that a implementor could choose a different default >>>>>>>> implementation on one of the recent threads that was up for >>>>>>>> review. >>>>>>>> >>>>>>>> I am still trying to understand what our guidelines are, if any >>>>>>>> for documenting the behavior of the supplied default methods >>>>>>>> given the javadocs are part of the specification for many APIs >>>>>>>> (and in some case the only spec). >>>>>>>> >>>>>>>> Best >>>>>>>> Lance >>>>>>>> >>>>>>>> Lance Andersen| Principal Member of Technical Staff | >>>>>>>> +1.781.442.2037 >>>>>>>> Oracle Java Engineering >>>>>>>> 1 Network Drive >>>>>>>> Burlington, MA 01803 >>>>>>>> Lance.Andersen at oracle.com >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>>> >>>> >>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >>>> >>>> >>> > From chris.hegarty at oracle.com Fri Dec 14 01:54:01 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 14 Dec 2012 09:54:01 +0000 Subject: signatures that are recorded for default methods In-Reply-To: <50CAF454.4040309@gmail.com> References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> <50CA4320.40408@oracle.com> <50CA61DA.7050205@oracle.com> <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> <50CAC55A.3010602@oracle.com> <50CAEC32.6060802@gmail.com> <50CAF454.4040309@gmail.com> Message-ID: <50CAF739.7080203@oracle.com> On 14/12/2012 09:41, Peter Levart wrote: > On 12/14/2012 10:06 AM, Peter Levart wrote: >> On 12/14/2012 07:21 AM, David Holmes wrote: >>> Paul, >>> >>> On 14/12/2012 9:46 AM, Paul Benedict wrote: >>>> Lance, >>>> >>>> Good questions. Someone with authority will surely answer, but here's >>>> my armchair opinion... >>>> >>>> If the Javadoc is to specify how the default method executes, than >>>> that would naturally infer all default implementations must have a >>>> stated contract. You can't document the default execution behavior in >>>> the public API and then let a provider switch the behavior. The two go >>>> hand-in-hand, imo. >>> >>> I couldn't really make sense of that. :) The method has a contract. >>> The "default implementation" has to honor that contract. The question >>> is whether how the "default implementation" honors the method >>> contract is required to be part of a second contract. >>> >>> I hope that made sense :) >> I think that the answer is obvious. A default method provider has only >> as much freedom in choosing the implementation of the default method >> that particular implementation differences among various providers are >> not observable by the "sane" usage of the API. The only soft aspect >> might be performance. Any other behavioural difference should not be >> allowed. Otherwise there will be in-compatibilities among platform >> providers. >> >> For example, the default Iterator.remove() is implemented in Oracle's >> JDK as always throwing UnsupportedOperationException. The TCK should >> test for that and the Javadoc should specify that. > Ok, I admit that in this particular case and other similar cases (where > the default method does nothing useful), the specification could > alternatively specify: "The default method behaviour is unspecified and > useless. Don't call that method or make sure it is always overridden if > you call it" - the TCK in that case doesn't test the behaviour of such And forever more ever concrete Iterator implementation, that does not support remove, will have to implement the remove method to throw UOE. I think this is a big loss. -Chris. > method. > > Peter >> >> As Joe said, default interface methods are no different than any other >> overridable methods. They have a contract and behaviour. The behaviour >> can be changed (overriden) within constraints defined by contract, but >> the behaviour itself should also be specified and followed by >> different providers. >> >> Just my 2 cents. >> >> Regards, Peter >> >>> >>> David >>> ----- >>> >>> >>>> Paul >>>> >>>> On Thu, Dec 13, 2012 at 5:30 PM, Lance Andersen - Oracle >>>> wrote: >>>>> >>>>> On Dec 13, 2012, at 6:16 PM, Leonid Arbuzov wrote: >>>>> >>>>>> Good point, Joe. >>>>>> Those extra assertions for default methods can be checked >>>>>> by regular API tests separately from signature tests. >>>>> >>>>> I am not clear on this. See the message attached from David which >>>>> ask a similar question (from the attached email): >>>>> ------------------- >>>>> 2. It is not obvious to me that the JDK's choice for a default >>>>> implementation has to be _the_ only possible implementation choice. >>>>> In many/most cases there will be a very obvious choice, but that >>>>> doesn't mean that all suppliers of OpenJDK classes have to be >>>>> locked in to that choice. >>>>> ------------------- >>>>> >>>>> >>>>> If everyone needs to implement the same default implementation then >>>>> great the JCK/TCK can test it and IMHO we should have a javadoc tag >>>>> for this. >>>>> >>>>> If everyone is free to choose what the default behavior is, then we >>>>> cannot test it. >>>>> >>>>> So has there been a decision WRT the requirements for default methods? >>>>> >>>>> >>>>> Best >>>>> Lance >>>>>> Thanks, >>>>>> -leonid >>>>>> >>>>>> On 12/13/2012 1:05 PM, Joe Darcy wrote: >>>>>>> Hello, >>>>>>> >>>>>>> As with concrete methods on abstract classes, I would expect the >>>>>>> specifications of the default methods to often contain text akin >>>>>>> to "This default implementation does x, y, and z" since if the >>>>>>> method is to be called by subtypes, the self-use patterns in the >>>>>>> default method need to be known. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> -Joe >>>>>>> >>>>>>> On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: >>>>>>>> Hello Lance, >>>>>>>> >>>>>>>> My understanding would be that the signature test >>>>>>>> should check that interface method is marked as default method >>>>>>>> but do not track the code in its default body >>>>>>>> (assuming that the body is not a part of a spec - API javadoc). >>>>>>>> >>>>>>>> (I've confirmed that with the signature test developer) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -leonid >>>>>>>> >>>>>>>> On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: >>>>>>>>> Folks, >>>>>>>>> >>>>>>>>> Will the signatures for interfaces that are recorded by the >>>>>>>>> TCKs for interfaces record the fact that a method includes a >>>>>>>>> default method? or will it just record the method definition? >>>>>>>>> >>>>>>>>> I am assuming it will, but I know there has been discussion >>>>>>>>> that a implementor could choose a different default >>>>>>>>> implementation on one of the recent threads that was up for >>>>>>>>> review. >>>>>>>>> >>>>>>>>> I am still trying to understand what our guidelines are, if any >>>>>>>>> for documenting the behavior of the supplied default methods >>>>>>>>> given the javadocs are part of the specification for many APIs >>>>>>>>> (and in some case the only spec). >>>>>>>>> >>>>>>>>> Best >>>>>>>>> Lance >>>>>>>>> >>>>>>>>> Lance Andersen| Principal Member of Technical Staff | >>>>>>>>> +1.781.442.2037 >>>>>>>>> Oracle Java Engineering >>>>>>>>> 1 Network Drive >>>>>>>>> Burlington, MA 01803 >>>>>>>>> Lance.Andersen at oracle.com >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>> Oracle Java Engineering >>>>> 1 Network Drive >>>>> Burlington, MA 01803 >>>>> Lance.Andersen at oracle.com >>>>> >>>>> >>>>> >>>> >> > From scolebourne at joda.org Fri Dec 14 02:24:04 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 14 Dec 2012 10:24:04 +0000 Subject: Feedback on the implementation of StringJoiner In-Reply-To: <50CA290F.4010402@oracle.com> References: <50B8D792.9060601@oracle.com> <50CA290F.4010402@oracle.com> Message-ID: On 13 December 2012 19:14, Henry Jen wrote: So, why is this class not final? I'm struggling to think of a case where extending it would be useful, and making it final generally makes it safer. Stephen From forax at univ-mlv.fr Fri Dec 14 02:54:51 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 14 Dec 2012 11:54:51 +0100 Subject: RFR: 8005051: default methods for Iterator In-Reply-To: <50CA7FD3.5020701@oracle.com> References: <50CA7FD3.5020701@oracle.com> Message-ID: <50CB057B.3070203@univ-mlv.fr> Hi Akhil, On 12/14/2012 02:24 AM, Akhil Arora wrote: > As part of the library lambdafication, this patch adds a forEach default > method to Iterator, and converts remove() into a default method so that > implementations of Iterator no longer have to override remove if they > desire the default behavior, which is to throw an > UnsupportedOperationException. > > http://cr.openjdk.java.net/~akhil/8005051.0/webrev/ > > The above patch requires a small patch to an internal class which > happens to implement both Iterable and Iterator. Now both Iterable and > Iterator supply a default forEach method, so the compiler balks. One > minimally intrusive solution is for this class to override both defaults > and provide its own version of forEach. > > http://cr.openjdk.java.net/~akhil/8005053.0/webrev/ The issue here is in the code of ASM wich is an external library imported in the JDK, so not sure it's a good idea to patch it. Moreover, goggling for "implement Iterable, Iterator" shows that this anti-pattern is used too frequently to not step back and see if a better solution is not possible. https://encrypted.google.com/search?hl=en&q=%22implements+Iterable%3C*%3E%2C+Iterator%3C*%3E%22 We can't remove Collection.forEach without having perf issue because the stream pipeline use it. Iterator.forEach can be removed but it's a pity because it's really convenient, a possble solution is to rename Iterator.forEach() to something else. > > Please review > Thanks > cheers, R?mi From chris.hegarty at oracle.com Fri Dec 14 03:46:57 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 14 Dec 2012 11:46:57 +0000 Subject: RFR: 8005051: default methods for Iterator In-Reply-To: <50CA7FD3.5020701@oracle.com> References: <50CA7FD3.5020701@oracle.com> Message-ID: <50CB11B1.5050105@oracle.com> On 14/12/2012 01:24, Akhil Arora wrote: > As part of the library lambdafication, this patch adds a forEach default > method to Iterator, and converts remove() into a default method so that > implementations of Iterator no longer have to override remove if they > desire the default behavior, which is to throw an > UnsupportedOperationException. This is not specified. Different Java SE implementations can have different default implementations of remove(). Your statement is either mistaken, or the changes will not meet their original intent. forEach, it is not clear to me if the method description is specifying what the default implementation is supposed to do, or if it is specifying the contract for the method. This, of course, has the same underlying cause as what is being discussed in other mail threads. I would like to see a clear decision being made around how default methods are to be specified before we start moving them into jdk8. -Chris. > > http://cr.openjdk.java.net/~akhil/8005051.0/webrev/ > > The above patch requires a small patch to an internal class which > happens to implement both Iterable and Iterator. Now both Iterable and > Iterator supply a default forEach method, so the compiler balks. One > minimally intrusive solution is for this class to override both defaults > and provide its own version of forEach. > > http://cr.openjdk.java.net/~akhil/8005053.0/webrev/ > > Please review > Thanks From Alan.Bateman at oracle.com Fri Dec 14 04:28:30 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Dec 2012 12:28:30 +0000 Subject: RFR: 8005051: default methods for Iterator In-Reply-To: <50CA7FD3.5020701@oracle.com> References: <50CA7FD3.5020701@oracle.com> Message-ID: <50CB1B6E.7030102@oracle.com> On 14/12/2012 01:24, Akhil Arora wrote: > As part of the library lambdafication, this patch adds a forEach > default method to Iterator, and converts remove() into a default > method so that implementations of Iterator no longer have to override > remove if they desire the default behavior, which is to throw an > UnsupportedOperationException. > > http://cr.openjdk.java.net/~akhil/8005051.0/webrev/ I looked at the changes to Iterator, a few minor comments: I think it would help to change "This default implementation" to "The default implementation", it makes it more obviously normative (and so testable) and might help for sub-types that override the method but don't inherit the javadoc. I assume the generated javadoc ends as a long paragraph, did you consider putting in

tags to make it a bit easier on the reader, minimally put the description of the default implementation isn't own paragraph. Should Collection have a lowercase "c" as it may be an iterator over a collection that is not a java.util.Collection? In forEach then it may be smoother to change "... execution subsequent ..." to "... execution then subsequent ...". As per the other thread, if new methods are coming with the public modifier then I think it should be added to the existing methods. -Alan. From ricky.clarkson at gmail.com Fri Dec 14 04:41:09 2012 From: ricky.clarkson at gmail.com (Ricky Clarkson) Date: Fri, 14 Dec 2012 09:41:09 -0300 Subject: signatures that are recorded for default methods In-Reply-To: <50CAF454.4040309@gmail.com> References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> <50CA4320.40408@oracle.com> <50CA61DA.7050205@oracle.com> <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> <50CAC55A.3010602@oracle.com> <50CAEC32.6060802@gmail.com> <50CAF454.4040309@gmail.com> Message-ID: Surely a default method that all subclasses are instructed to override just shouldn't exist, right? Then the compiler will 'instruct' subtypes to implement it automatically (i.e., by failing to compile). On Dec 14, 2012 6:42 AM, "Peter Levart" wrote: > On 12/14/2012 10:06 AM, Peter Levart wrote: > > On 12/14/2012 07:21 AM, David Holmes wrote: > >> Paul, > >> > >> On 14/12/2012 9:46 AM, Paul Benedict wrote: > >>> Lance, > >>> > >>> Good questions. Someone with authority will surely answer, but here's > >>> my armchair opinion... > >>> > >>> If the Javadoc is to specify how the default method executes, than > >>> that would naturally infer all default implementations must have a > >>> stated contract. You can't document the default execution behavior in > >>> the public API and then let a provider switch the behavior. The two go > >>> hand-in-hand, imo. > >> > >> I couldn't really make sense of that. :) The method has a contract. > >> The "default implementation" has to honor that contract. The question > >> is whether how the "default implementation" honors the method > >> contract is required to be part of a second contract. > >> > >> I hope that made sense :) > > I think that the answer is obvious. A default method provider has only > > as much freedom in choosing the implementation of the default method > > that particular implementation differences among various providers are > > not observable by the "sane" usage of the API. The only soft aspect > > might be performance. Any other behavioural difference should not be > > allowed. Otherwise there will be in-compatibilities among platform > > providers. > > > > For example, the default Iterator.remove() is implemented in Oracle's > > JDK as always throwing UnsupportedOperationException. The TCK should > > test for that and the Javadoc should specify that. > Ok, I admit that in this particular case and other similar cases (where > the default method does nothing useful), the specification could > alternatively specify: "The default method behaviour is unspecified and > useless. Don't call that method or make sure it is always overridden if > you call it" - the TCK in that case doesn't test the behaviour of such > method. > > Peter > > > > As Joe said, default interface methods are no different than any other > > overridable methods. They have a contract and behaviour. The behaviour > > can be changed (overriden) within constraints defined by contract, but > > the behaviour itself should also be specified and followed by > > different providers. > > > > Just my 2 cents. > > > > Regards, Peter > > > >> > >> David > >> ----- > >> > >> > >>> Paul > >>> > >>> On Thu, Dec 13, 2012 at 5:30 PM, Lance Andersen - Oracle > >>> wrote: > >>>> > >>>> On Dec 13, 2012, at 6:16 PM, Leonid Arbuzov wrote: > >>>> > >>>>> Good point, Joe. > >>>>> Those extra assertions for default methods can be checked > >>>>> by regular API tests separately from signature tests. > >>>> > >>>> I am not clear on this. See the message attached from David which > >>>> ask a similar question (from the attached email): > >>>> ------------------- > >>>> 2. It is not obvious to me that the JDK's choice for a default > >>>> implementation has to be _the_ only possible implementation choice. > >>>> In many/most cases there will be a very obvious choice, but that > >>>> doesn't mean that all suppliers of OpenJDK classes have to be > >>>> locked in to that choice. > >>>> ------------------- > >>>> > >>>> > >>>> If everyone needs to implement the same default implementation then > >>>> great the JCK/TCK can test it and IMHO we should have a javadoc tag > >>>> for this. > >>>> > >>>> If everyone is free to choose what the default behavior is, then we > >>>> cannot test it. > >>>> > >>>> So has there been a decision WRT the requirements for default methods? > >>>> > >>>> > >>>> Best > >>>> Lance > >>>>> Thanks, > >>>>> -leonid > >>>>> > >>>>> On 12/13/2012 1:05 PM, Joe Darcy wrote: > >>>>>> Hello, > >>>>>> > >>>>>> As with concrete methods on abstract classes, I would expect the > >>>>>> specifications of the default methods to often contain text akin > >>>>>> to "This default implementation does x, y, and z" since if the > >>>>>> method is to be called by subtypes, the self-use patterns in the > >>>>>> default method need to be known. > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> -Joe > >>>>>> > >>>>>> On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: > >>>>>>> Hello Lance, > >>>>>>> > >>>>>>> My understanding would be that the signature test > >>>>>>> should check that interface method is marked as default method > >>>>>>> but do not track the code in its default body > >>>>>>> (assuming that the body is not a part of a spec - API javadoc). > >>>>>>> > >>>>>>> (I've confirmed that with the signature test developer) > >>>>>>> > >>>>>>> Thanks, > >>>>>>> -leonid > >>>>>>> > >>>>>>> On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: > >>>>>>>> Folks, > >>>>>>>> > >>>>>>>> Will the signatures for interfaces that are recorded by the > >>>>>>>> TCKs for interfaces record the fact that a method includes a > >>>>>>>> default method? or will it just record the method definition? > >>>>>>>> > >>>>>>>> I am assuming it will, but I know there has been discussion > >>>>>>>> that a implementor could choose a different default > >>>>>>>> implementation on one of the recent threads that was up for > >>>>>>>> review. > >>>>>>>> > >>>>>>>> I am still trying to understand what our guidelines are, if any > >>>>>>>> for documenting the behavior of the supplied default methods > >>>>>>>> given the javadocs are part of the specification for many APIs > >>>>>>>> (and in some case the only spec). > >>>>>>>> > >>>>>>>> Best > >>>>>>>> Lance > >>>>>>>> > >>>>>>>> Lance Andersen| Principal Member of Technical Staff | > >>>>>>>> +1.781.442.2037 > >>>>>>>> Oracle Java Engineering > >>>>>>>> 1 Network Drive > >>>>>>>> Burlington, MA 01803 > >>>>>>>> Lance.Andersen at oracle.com > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>> > >>>> > >>>> > >>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > >>>> Oracle Java Engineering > >>>> 1 Network Drive > >>>> Burlington, MA 01803 > >>>> Lance.Andersen at oracle.com > >>>> > >>>> > >>>> > >>> > > > > > From Lance.Andersen at oracle.com Fri Dec 14 04:50:48 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Fri, 14 Dec 2012 07:50:48 -0500 Subject: RFR: 8005051: default methods for Iterator In-Reply-To: <50CB1B6E.7030102@oracle.com> References: <50CA7FD3.5020701@oracle.com> <50CB1B6E.7030102@oracle.com> Message-ID: On Dec 14, 2012, at 7:28 AM, Alan Bateman wrote: > On 14/12/2012 01:24, Akhil Arora wrote: >> As part of the library lambdafication, this patch adds a forEach default method to Iterator, and converts remove() into a default method so that implementations of Iterator no longer have to override remove if they desire the default behavior, which is to throw an UnsupportedOperationException. >> >> http://cr.openjdk.java.net/~akhil/8005051.0/webrev/ > I looked at the changes to Iterator, a few minor comments: > > I think it would help to change "This default implementation" to "The default implementation", it makes it more obviously normative (and so testable) and might help for sub-types that override the method but don't inherit the javadoc. > > I assume the generated javadoc ends as a long paragraph, did you consider putting in

tags to make it a bit easier on the reader, minimally put the description of the default implementation isn't own paragraph. This is why i am a proponent of adding a javadoc tag for default methods so that everyone is consistent in where/how we document the default method. I worry if we do not developers will place this info in various places making it easy to overlook. > > Should Collection have a lowercase "c" as it may be an iterator over a collection that is not a java.util.Collection? > > In forEach then it may be smoother to change "... execution subsequent ..." to "... execution then subsequent ...". > > As per the other thread, if new methods are coming with the public modifier then I think it should be added to the existing methods. > > -Alan. > > -------------- next part -------------- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From paul.sandoz at oracle.com Fri Dec 14 04:56:01 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 14 Dec 2012 12:56:01 +0000 Subject: hg: lambda/lambda/jdk: 4 new changesets Message-ID: <20121214125726.557FA4716A@hg.openjdk.java.net> Changeset: 4c718c99a6fc Author: psandoz Date: 2012-12-14 13:54 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4c718c99a6fc Consolidate specific primitive iterator/iterable/spliterator into general primtive interfaces. ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/op/MatchOp.java ! src/share/classes/java/util/stream/op/SliceOp.java ! src/share/classes/java/util/stream/primitive/IntCumulateOp.java ! src/share/classes/java/util/stream/primitive/IntFilterOp.java ! src/share/classes/java/util/stream/primitive/IntFlatMapOp.java - src/share/classes/java/util/stream/primitive/IntIterable.java - src/share/classes/java/util/stream/primitive/IntIterator.java ! src/share/classes/java/util/stream/primitive/IntMapOp.java ! src/share/classes/java/util/stream/primitive/IntNode.java ! src/share/classes/java/util/stream/primitive/IntNodeBuilder.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java ! src/share/classes/java/util/stream/primitive/IntSpinedBuffer.java - src/share/classes/java/util/stream/primitive/IntSpliterator.java ! src/share/classes/java/util/stream/primitive/IntStream.java ! src/share/classes/java/util/stream/primitive/IntTeeOp.java ! src/share/classes/java/util/stream/primitive/IntToIntegerOp.java + src/share/classes/java/util/stream/primitive/PrimitiveIterable.java + src/share/classes/java/util/stream/primitive/PrimitiveIterator.java + src/share/classes/java/util/stream/primitive/PrimitiveSpliterator.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! src/share/classes/java/util/stream/primitive/RefToIntMapOp.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindAnyOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindFirstOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SpinedBufferTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java Changeset: 36ed48220b28 Author: psandoz Date: 2012-12-14 13:54 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/36ed48220b28 Enusure generic primitive types are referred to. This enables single implementations for empty instances and concatenation of iterators. ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/op/MatchOp.java ! src/share/classes/java/util/stream/op/SliceOp.java ! src/share/classes/java/util/stream/primitive/IntCumulateOp.java ! src/share/classes/java/util/stream/primitive/IntFilterOp.java ! src/share/classes/java/util/stream/primitive/IntFlatMapOp.java ! src/share/classes/java/util/stream/primitive/IntMapOp.java ! src/share/classes/java/util/stream/primitive/IntNode.java ! src/share/classes/java/util/stream/primitive/IntNodeBuilder.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java ! src/share/classes/java/util/stream/primitive/IntSpinedBuffer.java ! src/share/classes/java/util/stream/primitive/IntStream.java ! src/share/classes/java/util/stream/primitive/IntTeeOp.java ! src/share/classes/java/util/stream/primitive/IntToIntegerOp.java ! src/share/classes/java/util/stream/primitive/PrimitiveIterable.java ! src/share/classes/java/util/stream/primitive/PrimitiveSpliterator.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindAnyOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindFirstOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SpinedBufferTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java Changeset: 5fc1425aeff2 Author: psandoz Date: 2012-12-14 13:54 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5fc1425aeff2 Generalize empty implementations for PrimitiveIterator and PrimitiveSpliterator and concatenation of PrimitiveIterator instances. ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/op/SliceOp.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntSpinedBuffer.java ! src/share/classes/java/util/stream/primitive/Primitives.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java Changeset: c880746e9689 Author: psandoz Date: 2012-12-14 13:54 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c880746e9689 - Consolidate specific primitive node/node builder into general primitive interfaces. - Generalize empty node implementation and conc'ing of nodes. ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/op/FindOp.java ! src/share/classes/java/util/stream/op/MatchOp.java + src/share/classes/java/util/stream/op/NodeUtils.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/op/SliceOp.java - src/share/classes/java/util/stream/op/TreeUtils.java ! src/share/classes/java/util/stream/primitive/IntCumulateOp.java ! src/share/classes/java/util/stream/primitive/IntFilterOp.java ! src/share/classes/java/util/stream/primitive/IntFlatMapOp.java ! src/share/classes/java/util/stream/primitive/IntMapOp.java - src/share/classes/java/util/stream/primitive/IntNode.java - src/share/classes/java/util/stream/primitive/IntNodeBuilder.java + src/share/classes/java/util/stream/primitive/IntNodeUtils.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java ! src/share/classes/java/util/stream/primitive/IntSpinedBuffer.java ! src/share/classes/java/util/stream/primitive/IntTeeOp.java ! src/share/classes/java/util/stream/primitive/IntToArrayOp.java ! src/share/classes/java/util/stream/primitive/IntToIntegerOp.java - src/share/classes/java/util/stream/primitive/IntTreeUtils.java + src/share/classes/java/util/stream/primitive/PrimitiveNode.java + src/share/classes/java/util/stream/primitive/PrimitiveNodeBuilder.java + src/share/classes/java/util/stream/primitive/PrimitiveNodes.java ! src/share/classes/java/util/stream/primitive/PrimitiveStreams.java < src/share/classes/java/util/stream/primitive/Primitives.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/ParallelRangeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ForEachOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MatchOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/PrimitiveOpsTests.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SpinedBufferTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntCumulateOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntFlatMapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntMinMaxTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntReduceTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntSliceOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntUniqOpTest.java From paul.sandoz at oracle.com Fri Dec 14 05:00:43 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 14 Dec 2012 14:00:43 +0100 Subject: RFR: 8005051: default methods for Iterator In-Reply-To: <50CB057B.3070203@univ-mlv.fr> References: <50CA7FD3.5020701@oracle.com> <50CB057B.3070203@univ-mlv.fr> Message-ID: On Dec 14, 2012, at 11:54 AM, Remi Forax wrote: > > We can't remove Collection.forEach without having perf issue because the stream pipeline use it. > Iterator.forEach can be removed but it's a pity because it's really convenient, And a case can be made performance wise too (there are optimal implementations in the stream code base). I have found that forEach, in general, has been very useful. Since it abstracts away the details of traversal it has enabled better re-use of code. Paul. > a possble solution is to rename Iterator.forEach() to something else. > >> >> Please review >> Thanks >> > > cheers, > R?mi > From forax at univ-mlv.fr Fri Dec 14 05:34:37 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 14 Dec 2012 14:34:37 +0100 Subject: RFR: 8005051: default methods for Iterator In-Reply-To: References: <50CA7FD3.5020701@oracle.com> <50CB057B.3070203@univ-mlv.fr> Message-ID: <50CB2AED.4030005@univ-mlv.fr> On 12/14/2012 02:00 PM, Paul Sandoz wrote: > On Dec 14, 2012, at 11:54 AM, Remi Forax wrote: >> We can't remove Collection.forEach without having perf issue because the stream pipeline use it. >> Iterator.forEach can be removed but it's a pity because it's really convenient, > And a case can be made performance wise too (there are optimal implementations in the stream code base). > > I have found that forEach, in general, has been very useful. Since it abstracts away the details of traversal it has enabled better re-use of code. thinking a little bit more about what you said, for the sequential implementation of the pipeline, there is no reason to use Iterator.forEach, if you can use forEach, it means that the logic can be encapsulated in a forEach, so the terminal op is not a short-circuited operation, so you can write it without an iterator. in the parallel case, it's different because the Spliterator exports only the data as an Iterator. > > Paul. R?mi > >> a possble solution is to rename Iterator.forEach() to something else. >> >>> Please review >>> Thanks >>> >> cheers, >> R?mi >> From peter.levart at gmail.com Fri Dec 14 06:13:07 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 14 Dec 2012 15:13:07 +0100 Subject: signatures that are recorded for default methods In-Reply-To: References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> <50CA4320.40408@oracle.com> <50CA61DA.7050205@oracle.com> <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> <50CAC55A.3010602@oracle.com> <50CAEC32.6060802@gmail.com> <50CAF454.4040309@gmail.com> Message-ID: <50CB33F3.8020309@gmail.com> On 12/14/2012 01:41 PM, Ricky Clarkson wrote: > > Surely a default method that all subclasses are instructed to override > just shouldn't exist, right? > > Then the compiler will 'instruct' subtypes to implement it > automatically (i.e., by failing to compile). > I just wanted to illustrate how a sub-optimal specification of default method behaviour for "optional" methods would sound like if one didn't want to specify that it always throws UnsupportedOperationException ;-) Peter > On Dec 14, 2012 6:42 AM, "Peter Levart" > wrote: > > On 12/14/2012 10:06 AM, Peter Levart wrote: > > On 12/14/2012 07:21 AM, David Holmes wrote: > >> Paul, > >> > >> On 14/12/2012 9:46 AM, Paul Benedict wrote: > >>> Lance, > >>> > >>> Good questions. Someone with authority will surely answer, but > here's > >>> my armchair opinion... > >>> > >>> If the Javadoc is to specify how the default method executes, than > >>> that would naturally infer all default implementations must have a > >>> stated contract. You can't document the default execution > behavior in > >>> the public API and then let a provider switch the behavior. > The two go > >>> hand-in-hand, imo. > >> > >> I couldn't really make sense of that. :) The method has a contract. > >> The "default implementation" has to honor that contract. The > question > >> is whether how the "default implementation" honors the method > >> contract is required to be part of a second contract. > >> > >> I hope that made sense :) > > I think that the answer is obvious. A default method provider > has only > > as much freedom in choosing the implementation of the default method > > that particular implementation differences among various > providers are > > not observable by the "sane" usage of the API. The only soft aspect > > might be performance. Any other behavioural difference should not be > > allowed. Otherwise there will be in-compatibilities among platform > > providers. > > > > For example, the default Iterator.remove() is implemented in > Oracle's > > JDK as always throwing UnsupportedOperationException. The TCK should > > test for that and the Javadoc should specify that. > Ok, I admit that in this particular case and other similar cases > (where > the default method does nothing useful), the specification could > alternatively specify: "The default method behaviour is > unspecified and > useless. Don't call that method or make sure it is always > overridden if > you call it" - the TCK in that case doesn't test the behaviour of such > method. > > Peter > > > > As Joe said, default interface methods are no different than any > other > > overridable methods. They have a contract and behaviour. The > behaviour > > can be changed (overriden) within constraints defined by > contract, but > > the behaviour itself should also be specified and followed by > > different providers. > > > > Just my 2 cents. > > > > Regards, Peter > > > >> > >> David > >> ----- > >> > >> > >>> Paul > >>> > >>> On Thu, Dec 13, 2012 at 5:30 PM, Lance Andersen - Oracle > >>> > > wrote: > >>>> > >>>> On Dec 13, 2012, at 6:16 PM, Leonid Arbuzov wrote: > >>>> > >>>>> Good point, Joe. > >>>>> Those extra assertions for default methods can be checked > >>>>> by regular API tests separately from signature tests. > >>>> > >>>> I am not clear on this. See the message attached from David > which > >>>> ask a similar question (from the attached email): > >>>> ------------------- > >>>> 2. It is not obvious to me that the JDK's choice for a default > >>>> implementation has to be _the_ only possible implementation > choice. > >>>> In many/most cases there will be a very obvious choice, but that > >>>> doesn't mean that all suppliers of OpenJDK classes have to be > >>>> locked in to that choice. > >>>> ------------------- > >>>> > >>>> > >>>> If everyone needs to implement the same default > implementation then > >>>> great the JCK/TCK can test it and IMHO we should have a > javadoc tag > >>>> for this. > >>>> > >>>> If everyone is free to choose what the default behavior is, > then we > >>>> cannot test it. > >>>> > >>>> So has there been a decision WRT the requirements for default > methods? > >>>> > >>>> > >>>> Best > >>>> Lance > >>>>> Thanks, > >>>>> -leonid > >>>>> > >>>>> On 12/13/2012 1:05 PM, Joe Darcy wrote: > >>>>>> Hello, > >>>>>> > >>>>>> As with concrete methods on abstract classes, I would > expect the > >>>>>> specifications of the default methods to often contain text > akin > >>>>>> to "This default implementation does x, y, and z" since if the > >>>>>> method is to be called by subtypes, the self-use patterns > in the > >>>>>> default method need to be known. > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> -Joe > >>>>>> > >>>>>> On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: > >>>>>>> Hello Lance, > >>>>>>> > >>>>>>> My understanding would be that the signature test > >>>>>>> should check that interface method is marked as default method > >>>>>>> but do not track the code in its default body > >>>>>>> (assuming that the body is not a part of a spec - API > javadoc). > >>>>>>> > >>>>>>> (I've confirmed that with the signature test developer) > >>>>>>> > >>>>>>> Thanks, > >>>>>>> -leonid > >>>>>>> > >>>>>>> On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: > >>>>>>>> Folks, > >>>>>>>> > >>>>>>>> Will the signatures for interfaces that are recorded by the > >>>>>>>> TCKs for interfaces record the fact that a method includes a > >>>>>>>> default method? or will it just record the method definition? > >>>>>>>> > >>>>>>>> I am assuming it will, but I know there has been discussion > >>>>>>>> that a implementor could choose a different default > >>>>>>>> implementation on one of the recent threads that was up for > >>>>>>>> review. > >>>>>>>> > >>>>>>>> I am still trying to understand what our guidelines are, > if any > >>>>>>>> for documenting the behavior of the supplied default methods > >>>>>>>> given the javadocs are part of the specification for many > APIs > >>>>>>>> (and in some case the only spec). > >>>>>>>> > >>>>>>>> Best > >>>>>>>> Lance > >>>>>>>> > >>>>>>>> Lance Andersen| Principal Member of Technical Staff | > >>>>>>>> +1.781.442.2037 > >>>>>>>> Oracle Java Engineering > >>>>>>>> 1 Network Drive > >>>>>>>> Burlington, MA 01803 > >>>>>>>> Lance.Andersen at oracle.com > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>> > >>>> > >>>> > >>>> Lance Andersen| Principal Member of Technical Staff | > +1.781.442.2037 > >>>> Oracle Java Engineering > >>>> 1 Network Drive > >>>> Burlington, MA 01803 > >>>> Lance.Andersen at oracle.com > >>>> > >>>> > >>>> > >>> > > > > From zhong.j.yu at gmail.com Fri Dec 14 06:42:31 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Fri, 14 Dec 2012 08:42:31 -0600 Subject: RFR: 8005051: default methods for Iterator In-Reply-To: <50CB057B.3070203@univ-mlv.fr> References: <50CA7FD3.5020701@oracle.com> <50CB057B.3070203@univ-mlv.fr> Message-ID: On Fri, Dec 14, 2012 at 4:54 AM, Remi Forax wrote: > Hi Akhil, > > On 12/14/2012 02:24 AM, Akhil Arora wrote: >> >> As part of the library lambdafication, this patch adds a forEach default >> method to Iterator, and converts remove() into a default method so that >> implementations of Iterator no longer have to override remove if they >> desire the default behavior, which is to throw an >> UnsupportedOperationException. >> >> http://cr.openjdk.java.net/~akhil/8005051.0/webrev/ >> >> The above patch requires a small patch to an internal class which >> happens to implement both Iterable and Iterator. Now both Iterable and >> Iterator supply a default forEach method, so the compiler balks. One >> minimally intrusive solution is for this class to override both defaults >> and provide its own version of forEach. >> >> http://cr.openjdk.java.net/~akhil/8005053.0/webrev/ > > > The issue here is in the code of ASM wich is an external library imported in > the JDK, > so not sure it's a good idea to patch it. > > Moreover, goggling for "implement Iterable, Iterator" shows that this > anti-pattern is used too frequently to not step back and see if a better > solution is not possible. > https://encrypted.google.com/search?hl=en&q=%22implements+Iterable%3C*%3E%2C+Iterator%3C*%3E%22 > > We can't remove Collection.forEach without having perf issue because the > stream pipeline use it. > Iterator.forEach can be removed but it's a pity because it's really > convenient, > a possble solution is to rename Iterator.forEach() to something else. I agree with renaming the method; it shouldn't be confused with the typical forEach() on a collection which visits *all* elements; here it only visits the remaining elements. >> >> Please review >> Thanks >> > > cheers, > R?mi > From paul.sandoz at oracle.com Fri Dec 14 06:47:55 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 14 Dec 2012 15:47:55 +0100 Subject: RFR: 8005051: default methods for Iterator In-Reply-To: <50CB2AED.4030005@univ-mlv.fr> References: <50CA7FD3.5020701@oracle.com> <50CB057B.3070203@univ-mlv.fr> <50CB2AED.4030005@univ-mlv.fr> Message-ID: <77BB6EA4-061E-48F5-AAF7-379687AF177F@oracle.com> On Dec 14, 2012, at 2:34 PM, Remi Forax wrote: > On 12/14/2012 02:00 PM, Paul Sandoz wrote: >> On Dec 14, 2012, at 11:54 AM, Remi Forax wrote: >>> We can't remove Collection.forEach without having perf issue because the stream pipeline use it. >>> Iterator.forEach can be removed but it's a pity because it's really convenient, >> And a case can be made performance wise too (there are optimal implementations in the stream code base). >> >> I have found that forEach, in general, has been very useful. Since it abstracts away the details of traversal it has enabled better re-use of code. > > thinking a little bit more about what you said, for the sequential implementation of the pipeline, there is no reason to use Iterator.forEach, > if you can use forEach, it means that the logic can be encapsulated in a forEach, so the terminal op is not a short-circuited operation, > so you can write it without an iterator. > It's used in the sequential case when the pipeline is short circuited: @Override public> S into(S sink) { Objects.requireNonNull(sink); if (isShortCircuit()) { sink.begin(getOutputSizeIfKnown()); iterator().forEach(sink); sink.end(); } else { super.into(sink); } return sink; } Paul. From pbenedict at apache.org Fri Dec 14 07:01:03 2012 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 14 Dec 2012 09:01:03 -0600 Subject: signatures that are recorded for default methods In-Reply-To: <50CAC55A.3010602@oracle.com> References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> <50CA4320.40408@oracle.com> <50CA61DA.7050205@oracle.com> <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> <50CAC55A.3010602@oracle.com> Message-ID: David, forgive me for lousy sentence construction :-) There's no way to say "The default implementation does..." and not have it be part of the interface spec. Whatever the default method does becomes the stated contract for any other implementation of OpenJDK. Paul On Fri, Dec 14, 2012 at 12:21 AM, David Holmes wrote: > Paul, > > > On 14/12/2012 9:46 AM, Paul Benedict wrote: >> >> Lance, >> >> Good questions. Someone with authority will surely answer, but here's >> my armchair opinion... >> >> If the Javadoc is to specify how the default method executes, than >> that would naturally infer all default implementations must have a >> stated contract. You can't document the default execution behavior in >> the public API and then let a provider switch the behavior. The two go >> hand-in-hand, imo. > > > I couldn't really make sense of that. :) The method has a contract. The > "default implementation" has to honor that contract. The question is whether > how the "default implementation" honors the method contract is required to > be part of a second contract. > > I hope that made sense :) > > David > ----- > > > >> Paul >> >> On Thu, Dec 13, 2012 at 5:30 PM, Lance Andersen - Oracle >> wrote: >>> >>> >>> On Dec 13, 2012, at 6:16 PM, Leonid Arbuzov wrote: >>> >>>> Good point, Joe. >>>> Those extra assertions for default methods can be checked >>>> by regular API tests separately from signature tests. >>> >>> >>> I am not clear on this. See the message attached from David which ask a >>> similar question (from the attached email): >>> ------------------- >>> 2. It is not obvious to me that the JDK's choice for a default >>> implementation has to be _the_ only possible implementation choice. In >>> many/most cases there will be a very obvious choice, but that doesn't mean >>> that all suppliers of OpenJDK classes have to be locked in to that choice. >>> ------------------- >>> >>> >>> If everyone needs to implement the same default implementation then great >>> the JCK/TCK can test it and IMHO we should have a javadoc tag for this. >>> >>> If everyone is free to choose what the default behavior is, then we >>> cannot test it. >>> >>> So has there been a decision WRT the requirements for default methods? >>> >>> >>> Best >>> Lance >>>> >>>> Thanks, >>>> -leonid >>>> >>>> On 12/13/2012 1:05 PM, Joe Darcy wrote: >>>>> >>>>> Hello, >>>>> >>>>> As with concrete methods on abstract classes, I would expect the >>>>> specifications of the default methods to often contain text akin to "This >>>>> default implementation does x, y, and z" since if the method is to be called >>>>> by subtypes, the self-use patterns in the default method need to be known. >>>>> >>>>> Cheers, >>>>> >>>>> -Joe >>>>> >>>>> On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: >>>>>> >>>>>> Hello Lance, >>>>>> >>>>>> My understanding would be that the signature test >>>>>> should check that interface method is marked as default method >>>>>> but do not track the code in its default body >>>>>> (assuming that the body is not a part of a spec - API javadoc). >>>>>> >>>>>> (I've confirmed that with the signature test developer) >>>>>> >>>>>> Thanks, >>>>>> -leonid >>>>>> >>>>>> On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> Will the signatures for interfaces that are recorded by the TCKs for >>>>>>> interfaces record the fact that a method includes a default method? or will >>>>>>> it just record the method definition? >>>>>>> >>>>>>> I am assuming it will, but I know there has been discussion that a >>>>>>> implementor could choose a different default implementation on one of the >>>>>>> recent threads that was up for review. >>>>>>> >>>>>>> I am still trying to understand what our guidelines are, if any for >>>>>>> documenting the behavior of the supplied default methods given the javadocs >>>>>>> are part of the specification for many APIs (and in some case the only >>>>>>> spec). >>>>>>> >>>>>>> Best >>>>>>> Lance >>>>>>> >>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>>>> Oracle Java Engineering >>>>>>> 1 Network Drive >>>>>>> Burlington, MA 01803 >>>>>>> Lance.Andersen at oracle.com >>>>>>> >>>>>>> >>>>>> >>>>> >>> >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> >> > From forax at univ-mlv.fr Fri Dec 14 08:21:26 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 14 Dec 2012 17:21:26 +0100 Subject: RFR: 8005051: default methods for Iterator In-Reply-To: <77BB6EA4-061E-48F5-AAF7-379687AF177F@oracle.com> References: <50CA7FD3.5020701@oracle.com> <50CB057B.3070203@univ-mlv.fr> <50CB2AED.4030005@univ-mlv.fr> <77BB6EA4-061E-48F5-AAF7-379687AF177F@oracle.com> Message-ID: <50CB5206.5030209@univ-mlv.fr> On 12/14/2012 03:47 PM, Paul Sandoz wrote: > On Dec 14, 2012, at 2:34 PM, Remi Forax wrote: > >> On 12/14/2012 02:00 PM, Paul Sandoz wrote: >>> On Dec 14, 2012, at 11:54 AM, Remi Forax wrote: >>>> We can't remove Collection.forEach without having perf issue because the stream pipeline use it. >>>> Iterator.forEach can be removed but it's a pity because it's really convenient, >>> And a case can be made performance wise too (there are optimal implementations in the stream code base). >>> >>> I have found that forEach, in general, has been very useful. Since it abstracts away the details of traversal it has enabled better re-use of code. >> thinking a little bit more about what you said, for the sequential implementation of the pipeline, there is no reason to use Iterator.forEach, >> if you can use forEach, it means that the logic can be encapsulated in a forEach, so the terminal op is not a short-circuited operation, >> so you can write it without an iterator. >> > It's used in the sequential case when the pipeline is short circuited: > > @Override > public> S into(S sink) { > Objects.requireNonNull(sink); > > if (isShortCircuit()) { > sink.begin(getOutputSizeIfKnown()); > iterator().forEach(sink); > sink.end(); > } else { > super.into(sink); > } > > return sink; > } I think you don't need to use an iterator for that, by example if you want to implement findFirst() all you need is to have a method findFirst() in every node that returns the first node found. > > Paul. > R?mi From paul.sandoz at oracle.com Fri Dec 14 08:14:43 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 14 Dec 2012 16:14:43 +0000 Subject: hg: lambda/lambda/jdk: - change "int size()" to "long count()" Message-ID: <20121214161505.D23BD4716D@hg.openjdk.java.net> Changeset: cc5c324cb654 Author: psandoz Date: 2012-12-14 17:14 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/cc5c324cb654 - change "int size()" to "long count()" Method name change is so that it does not clash with Collection.size() - {Int}SpinedBuffer and {Int}ConcNode can hold up to Long.MAX_VALUE elements. ! src/share/classes/java/util/stream/op/Node.java ! src/share/classes/java/util/stream/op/NodeBuilder.java ! src/share/classes/java/util/stream/op/NodeUtils.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/op/SliceOp.java ! src/share/classes/java/util/stream/op/SpinedBuffer.java ! src/share/classes/java/util/stream/primitive/IntNodeUtils.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntSpinedBuffer.java ! src/share/classes/java/util/stream/primitive/PrimitiveNodes.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/CumulateOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FilterOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlatMapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeBuilderTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SliceOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SortedOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SpinedBufferTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UniqOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntCumulateOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntFilterOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntFlatMapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntSliceOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntUniqOpTest.java From henry.jen at oracle.com Fri Dec 14 08:54:43 2012 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 14 Dec 2012 08:54:43 -0800 Subject: Feedback on the implementation of StringJoiner In-Reply-To: References: <50B8D792.9060601@oracle.com> <50C67FD6.2040808@univ-mlv.fr> <50C69761.8050400@oracle.com> <50C6E9E3.4000506@univ-mlv.fr> <50C9A1E8.4020908@univ-mlv.fr> <50CA29EE.7070006@oracle.com> Message-ID: <4A03178C-EBA3-48B5-B99B-3FF4CE04AD8D@oracle.com> On Dec 14, 2012, at 1:31 AM, Roel Spilker wrote: > It is already pushed to the lambda repo: http://hg.openjdk.java.net/lambda/lambda/jdk/annotate/6fb8cefc938c/src/share/classes/java/util/StringJoiner.java > > I'm not sure that that's correct. If the prefix and the first added element are both empty and the infix is not, I would expect the resulting String to start with the infix, but in this implementation it starts with the first added non-empty CharSequence. Good catch. Will fix and add a test case. > So I think we still need the somethingAdded field, or need to initialize the value field with null and construct the value when the first value is added. > > Also, the lambda implementation still does the string concatenation in the constructor. > Yes, see previous reply. I am not convinced it should be removed. Cheers, Henry From henry.jen at oracle.com Fri Dec 14 09:06:23 2012 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 14 Dec 2012 09:06:23 -0800 Subject: Feedback on the implementation of StringJoiner In-Reply-To: References: <50B8D792.9060601@oracle.com> <50CA290F.4010402@oracle.com> Message-ID: <31045B8D-DD12-479B-A088-16B91400B45D@oracle.com> On Dec 14, 2012, at 2:24 AM, Stephen Colebourne wrote: > On 13 December 2012 19:14, Henry Jen wrote: > > So, why is this class not final? > > I'm struggling to think of a case where extending it would be useful, > and making it final generally makes it safer. > There are something we decided not needed but probably not for others, for example, while we believe most use cases coming from stream, and use alternative representation for empty or null elements should be done outside the joiner, one may choose to extend the joiner to support that in general. Sure that can also be implemented via delegation, just to illustrate a possibility. Cheers, Henry From paul.sandoz at oracle.com Fri Dec 14 09:46:08 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 14 Dec 2012 18:46:08 +0100 Subject: RFR: 8005051: default methods for Iterator In-Reply-To: <50CB5206.5030209@univ-mlv.fr> References: <50CA7FD3.5020701@oracle.com> <50CB057B.3070203@univ-mlv.fr> <50CB2AED.4030005@univ-mlv.fr> <77BB6EA4-061E-48F5-AAF7-379687AF177F@oracle.com> <50CB5206.5030209@univ-mlv.fr> Message-ID: <627DACD0-10A3-4FDE-8B24-DE3C6CA6A049@oracle.com> On Dec 14, 2012, at 5:21 PM, Remi Forax wrote: > On 12/14/2012 03:47 PM, Paul Sandoz wrote: >> On Dec 14, 2012, at 2:34 PM, Remi Forax wrote: >> >>> On 12/14/2012 02:00 PM, Paul Sandoz wrote: >>>> On Dec 14, 2012, at 11:54 AM, Remi Forax wrote: >>>>> We can't remove Collection.forEach without having perf issue because the stream pipeline use it. >>>>> Iterator.forEach can be removed but it's a pity because it's really convenient, >>>> And a case can be made performance wise too (there are optimal implementations in the stream code base). >>>> >>>> I have found that forEach, in general, has been very useful. Since it abstracts away the details of traversal it has enabled better re-use of code. >>> thinking a little bit more about what you said, for the sequential implementation of the pipeline, there is no reason to use Iterator.forEach, >>> if you can use forEach, it means that the logic can be encapsulated in a forEach, so the terminal op is not a short-circuited operation, >>> so you can write it without an iterator. >>> >> It's used in the sequential case when the pipeline is short circuited: >> >> @Override >> public> S into(S sink) { >> Objects.requireNonNull(sink); >> >> if (isShortCircuit()) { >> sink.begin(getOutputSizeIfKnown()); >> iterator().forEach(sink); >> sink.end(); >> } else { >> super.into(sink); >> } >> >> return sink; >> } > > I think you don't need to use an iterator for that, That code above is a core piece of sequential stream functionality leveraged by *non-short circuiting* terminal ops, so those ops don't have to work out whether to push or pull the pipeline depending if there is an intermediate short-circuiting op (such as limit). Paul. From mike.duigou at oracle.com Fri Dec 14 10:58:09 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 14 Dec 2012 10:58:09 -0800 Subject: RFR : CR8004015 : Add parent interfaces and default methods to basic functional interfaces In-Reply-To: <50CAC719.7090308@oracle.com> References: <99DC2763-ED44-42CA-90F3-04AD07B2846D@oracle.com> <50CAC719.7090308@oracle.com> Message-ID: <0A9D8113-780C-4BA7-9380-AAD53A0DAA58@oracle.com> On Dec 13 2012, at 22:28 , David Holmes wrote: >> I have added @throws NPE for a number of the default methods. We won't be including @throws NPE in all cases where null is disallowed because when the @throws NPE is declared the API is required to throw NPE in that circumstance. So for cases where the NPE is "naturally" thrown or that aren't performance sensitive we will likely add @throws NPE declarations but for performance sensitive methods we won't be adding explicit null checks to match a @throws NPE specification. There's a tradeoff here in some cases. Please feel free to quibble about specific cases as they occur. :-) > > That doesn't make sense to me. The throwing of the NPE is intended to be part of the specification not an implementation choice. Further @param foo non-null, is just as binding on implementations as @throws NPE if foo is null. ??? An "@param foo non-null" by itself is not considered normative because it doesn't document what happens when null is passed. So it ends up being advisory only. An "@throws NPE" is considered normative and the implementation must throw in all circumstances described. (Please bear with the step-by-step nature of the following sample, it's incremental pace is not meant to be insulting--it's a write-up for a general FAQ). If I have a method: /** * If the object is visible then write it's string form to the provided PrintStream. * * @param bar destination for display / public void display(PrintStream bar) { if(visible) { bar.write(toString()); } } This implementation isn't going to work well if "bar" is ever null. So I document that in the "@param bar": /** * If the object is visible then write it's string form to the provided PrintStream. * * @param bar destination for display, must be non-null / public void display(PrintStream bar) { if(visible) { bar.write(toString()); } } The "@param bar" documentation now says that it must be non-null but doesn't explain what happens if null is passed. Having documented that null shouldn't be passed is helpful but not as helpful as it could be. To specify what happens I must add "@throws NPE": /** * If the object is visible then write it's string form to the provided PrintStream. * * @param bar destination for display, must be non-null * @throws NullPointerException if bar is null / public void display(PrintStream bar) { if(visible) { bar.write(toString()); } } This implementation would superficially seem to conform to the contract described in the javadoc. However, when the "if(visible)" conditional is false then no NPE will be thrown. Contract broken. It is required to add an explicit null check on "bar" ie. /** * If the object is visible then write it's string form to the provided PrintStream. * * @param bar destination for display, must be non-null * @throws NullPointerException if bar is null / public void display(PrintStream bar) { Objects.requireNonNull(bar); if(visible) { bar.write(toString()); } } Adding the "Objects.requireNonNull" ensures that the NPE is thrown in all appropriate cases. There is also another alternative: /** * If the object is visible then write it's string form to the provided PrintStream. * * @param bar destination for display, must be non-null * @throws NullPointerException if bar is null and the component is visible. / public void display(PrintStream bar) { if(visible) { bar.write(toString()); } } The conditions in which NPE are thrown are amended so that throwing is only required if the component is visible. Documenting the conditions could quickly become complicated if display was a more involved method. At some point it becomes easier to just add an explicit check. It can also be useful to add explicit NPE checks as pre-conditions before a multi-stage operation where a late stage NPE might corrupt the object state. In a very few cases an explicit null check might add too much overhead to a performance sensitive method and writing an accurate "@throws NPE" isn't possible (perhaps because of delegation) then the "@throws NPE" should be removed and only the advisory "@param bar ... must be non-null" will have to suffice. Mike > I think defining the NPE via the @param and @throws is a lose-lose situation: > > ! * @param left {@inheritDoc}, must be non-null > ! * @param right {@inheritDoc}, must be non-null > ! * @return {@inheritDoc}, always non-null > ! * @throws NullPointerException if {@code left} or {@code right} is null > > You only need one convention. > > David > ----- > > >> Mike From maurizio.cimadamore at oracle.com Fri Dec 14 11:04:24 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 14 Dec 2012 19:04:24 +0000 Subject: hg: lambda/lambda/langtools: 14 new changesets Message-ID: <20121214190503.8051D47177@hg.openjdk.java.net> Changeset: d9fe1f80515d Author: vromero Date: 2012-11-21 18:40 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d9fe1f80515d 7190862: javap shows an incorrect type for operands if the 'wide' prefix is used 7109747: (javap) classfile not treating iinc_w correctly. Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/classfile/Instruction.java ! src/share/classes/com/sun/tools/classfile/Opcode.java + test/tools/javap/T7190862.java Changeset: 3746b071d75b Author: vromero Date: 2012-11-21 19:09 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3746b071d75b 6574624: javax.tools.JavaCompiler spec contains errors in sample code Reviewed-by: jjg, mcimadamore ! src/share/classes/javax/tools/JavaCompiler.java Changeset: 4d68e2a05b50 Author: jjg Date: 2012-11-27 13:55 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/4d68e2a05b50 8004068: Fix build problems caused by on-demand imports Reviewed-by: jjg Contributed-by: eric.caspole at amd.com ! src/share/classes/com/sun/tools/javac/code/Types.java Changeset: 1f41a5758cf7 Author: vromero Date: 2012-11-23 15:13 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/1f41a5758cf7 7144981: javac should ignore ignorable characters in input Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java + test/tools/javac/7144981/IgnoreIgnorableCharactersInInput.java Changeset: 969c96b980b7 Author: vromero Date: 2012-11-29 09:41 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/969c96b980b7 7153958: add constant pool reference to class containing inlined constants Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/7153958/CPoolRefClassContainingInlinedCts.java + test/tools/javac/7153958/pkg/ClassToBeStaticallyImported.java Changeset: 4f9853659bf1 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/4f9853659bf1 8004105: Expression statement lambdas should be void-compatible Summary: Fix lambda compatibility rules as per latest EDR Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/lambda/LambdaConv21.java ! test/tools/javac/lambda/LambdaConv21.out ! test/tools/javac/lambda/VoidCompatibility.out Changeset: 34d1ebaf4645 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/34d1ebaf4645 8004102: Add support for generic functional descriptors Summary: Method references are allowed to have a generic functional interface descriptor target Reviewed-by: jjg ! 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/resources/compiler.properties - test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java + test/tools/javac/diags/examples/InvalidGenericLambdaTarget.java + test/tools/javac/lambda/FunctionalInterfaceConversionTest.java - test/tools/javac/lambda/LambdaConversionTest.java + test/tools/javac/lambda/MethodReference57.java + test/tools/javac/lambda/MethodReference58.java + test/tools/javac/lambda/MethodReference58.out Changeset: 9b26c96f5138 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/9b26c96f5138 8004101: Add checks for method reference well-formedness Summary: Bring method reference type-checking in sync with latest EDR Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/diags/examples/StaticBoundMref.java + test/tools/javac/diags/examples/StaticMrefWithTargs.java ! test/tools/javac/lambda/MethodReference30.java + test/tools/javac/lambda/MethodReference55.java + test/tools/javac/lambda/MethodReference55.out + test/tools/javac/lambda/MethodReference56.java + test/tools/javac/lambda/MethodReference56.out ! test/tools/javac/lambda/methodReference/MethodRef1.java ! test/tools/javac/lambda/methodReference/SamConversion.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java Changeset: f6f1fd261f57 Author: mcimadamore Date: 2012-11-30 15:14 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/f6f1fd261f57 8002099: Add support for intersection types in cast expression Summary: Add parser and type-checking support for intersection types in cast expressions Reviewed-by: jjg + src/share/classes/com/sun/source/tree/IntersectionTypeTree.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/javac/code/Source.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/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.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/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/javax/lang/model/type/IntersectionType.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/AbstractTypeVisitor8.java + test/tools/javac/cast/intersection/IntersectionTypeCastTest.java + test/tools/javac/cast/intersection/IntersectionTypeParserTest.java + test/tools/javac/cast/intersection/model/Check.java + test/tools/javac/cast/intersection/model/IntersectionTypeInfo.java + test/tools/javac/cast/intersection/model/Member.java + test/tools/javac/cast/intersection/model/Model01.java + test/tools/javac/cast/intersection/model/ModelChecker.java + test/tools/javac/diags/examples/IntersectionTypesInCastNotSupported.java + test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java + test/tools/javac/lambda/Intersection01.java + test/tools/javac/lambda/Intersection01.out ! test/tools/javac/lambda/LambdaParserTest.java + test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java Changeset: 98e14fc9ee11 Author: lana Date: 2012-11-30 16:34 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/98e14fc9ee11 Merge Changeset: 0e70eb71fec0 Author: mcimadamore Date: 2012-12-04 17:19 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/0e70eb71fec0 8004360: regression test DefaultMethodRegressionTests fails in langtools Summary: ignore broken failing test Reviewed-by: jjg - test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java + test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java Changeset: 014a6a11dfe5 Author: lana Date: 2012-12-10 20:59 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/014a6a11dfe5 Merge - test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/diags/examples/InvalidGenericDescInFunctionalInterface.java - test/tools/javac/lambda/LambdaConversionTest.java Changeset: 13ccb5269f3d Author: katleman Date: 2012-12-13 09:05 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/13ccb5269f3d Added tag jdk8-b68 for changeset 014a6a11dfe5 ! .hgtags Changeset: 2dd0e1a884ba Author: mcimadamore Date: 2012-12-14 18:40 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/2dd0e1a884ba merge with jdk8-b68 ! .hgtags ! 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/javac/code/Source.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/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.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/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.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/javax/lang/model/type/IntersectionType.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/AbstractTypeVisitor8.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/cast/intersection/model/ModelChecker.java - test/tools/javac/defaultMethodExecution/DefaultMethodRegressionTests.java ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/InvalidGenericLambdaTarget.java ! test/tools/javac/lambda/FunctionalInterfaceConversionTest.java ! test/tools/javac/lambda/Intersection01.java ! test/tools/javac/lambda/Intersection01.out ! test/tools/javac/lambda/LambdaConv21.java ! test/tools/javac/lambda/LambdaConv21.out - test/tools/javac/lambda/LambdaConversionTest.java ! test/tools/javac/lambda/LambdaParserTest.java ! test/tools/javac/lambda/MethodReference30.java ! test/tools/javac/lambda/MethodReference55.java ! test/tools/javac/lambda/MethodReference55.out ! test/tools/javac/lambda/MethodReference56.java ! test/tools/javac/lambda/MethodReference56.out ! test/tools/javac/lambda/MethodReference57.java ! test/tools/javac/lambda/MethodReference58.java ! test/tools/javac/lambda/MethodReference58.out ! test/tools/javac/lambda/VoidCompatibility.out ! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java From john.jullion-ceccarelli at oracle.com Fri Dec 14 11:07:11 2012 From: john.jullion-ceccarelli at oracle.com (John Ceccarelli) Date: Fri, 14 Dec 2012 11:07:11 -0800 Subject: All I want for Christmas is a Lambda-enabled NetBeans Build Message-ID: <50CB78DF.6010307@oracle.com> Santa came early :-) First off, wanted to introduce myself. I'm John Ceccarelli, director of engineering for NetBeans. We've been working hard with the OpenJDK team to provide support for Lambdas. You can check it out here: http://wiki.netbeans.org/JDK8 Please try it out and send feedback to us, either on this alias (which we'll be monitoring) or nbusers alias on netbeans.org: http://netbeans.org/community/lists/index.html Thanks! -J From paul.sandoz at oracle.com Fri Dec 14 11:42:35 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 14 Dec 2012 19:42:35 +0000 Subject: hg: lambda/lambda/jdk: Change accessor for Node children from an iterator to a get with index. Message-ID: <20121214194259.C0E2D47179@hg.openjdk.java.net> Changeset: 7266dd644226 Author: psandoz Date: 2012-12-14 20:42 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7266dd644226 Change accessor for Node children from an iterator to a get with index. ! src/share/classes/java/util/stream/op/Node.java ! src/share/classes/java/util/stream/op/NodeUtils.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/primitive/IntNodeUtils.java ! src/share/classes/java/util/stream/primitive/PrimitiveNode.java ! src/share/classes/java/util/stream/primitive/PrimitiveNodes.java From brian.goetz at oracle.com Fri Dec 14 12:57:44 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 14 Dec 2012 20:57:44 +0000 Subject: hg: lambda/lambda/jdk: First cut at replacing groupBy/reduceBy with Tabulator framework, supporting multi-level summarization and finer-grained control over creating intermediate containers. Explicitly support mutable vs functional reductions. Explicitly support concurrent vs merge-oriented reductions. Message-ID: <20121214205806.F3AAE4717D@hg.openjdk.java.net> Changeset: 5d25f6772fec Author: briangoetz Date: 2012-12-14 15:54 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5d25f6772fec First cut at replacing groupBy/reduceBy with Tabulator framework, supporting multi-level summarization and finer-grained control over creating intermediate containers. Explicitly support mutable vs functional reductions. Explicitly support concurrent vs merge-oriented reductions. ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Comparators.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java + src/share/classes/java/util/stream/op/ConcurrentTabulateOp.java ! src/share/classes/java/util/stream/op/FoldOp.java - src/share/classes/java/util/stream/op/GroupByOp.java ! src/share/classes/java/util/stream/op/OpUtils.java - src/share/classes/java/util/stream/op/ReduceByOp.java ! src/share/classes/java/util/stream/op/SliceOp.java + src/share/classes/java/util/stream/reduce/ConcurrentTabulator.java + src/share/classes/java/util/stream/reduce/ConcurrentTabulators.java + src/share/classes/java/util/stream/reduce/MutableReducer.java + src/share/classes/java/util/stream/reduce/Reducers.java + src/share/classes/java/util/stream/reduce/Tabulator.java + src/share/classes/java/util/stream/reduce/Tabulators.java + test-ng/tests/lambda/TestInnerCtorRef.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/GroupByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ReduceByOpTest.java From maurizio.cimadamore at oracle.com Fri Dec 14 14:12:01 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 14 Dec 2012 22:12:01 +0000 Subject: hg: lambda/lambda/langtools: Enhancement: Add backed support for indy calls to alternate metafactory Message-ID: <20121214221205.EB80847180@hg.openjdk.java.net> Changeset: 6acec3010e26 Author: mcimadamore Date: 2012-12-14 22:11 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/6acec3010e26 Enhancement: Add backed support for indy calls to alternate metafactory Serializable lambdas/method references should be created using an alternate bootstrap method. ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/Names.java From mike.duigou at oracle.com Fri Dec 14 18:00:18 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sat, 15 Dec 2012 02:00:18 +0000 Subject: hg: lambda/lambda/jdk: Fix: value.length() == 0 does not necessary represent StringJoiner is empty Message-ID: <20121215020040.4519E4718C@hg.openjdk.java.net> Changeset: 16e449dfdcda Author: henryjen Date: 2012-12-14 17:36 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/16e449dfdcda Fix: value.length() == 0 does not necessary represent StringJoiner is empty ! src/share/classes/java/util/StringJoiner.java ! test-ng/tests/org/openjdk/tests/java/util/StringJoinerTest.java From brian.goetz at oracle.com Fri Dec 14 20:25:38 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sat, 15 Dec 2012 04:25:38 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121215042609.EF7BE47191@hg.openjdk.java.net> Changeset: 85a719d0b9fa Author: briangoetz Date: 2012-12-14 23:24 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/85a719d0b9fa Some tests for tabulation ! src/share/classes/java/util/function/BiBlock.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/reduce/Reducers.java ! src/share/classes/java/util/stream/reduce/Tabulators.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java + test-ng/tests/org/openjdk/tests/java/util/stream/TabulatorsTest.java Changeset: 9ee55923515c Author: briangoetz Date: 2012-12-14 23:25 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9ee55923515c Merge From brian.goetz at oracle.com Fri Dec 14 20:52:05 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sat, 15 Dec 2012 04:52:05 +0000 Subject: hg: lambda/lambda/jdk: More tabulators Message-ID: <20121215045216.567A747193@hg.openjdk.java.net> Changeset: b4df0980faaa Author: briangoetz Date: 2012-12-14 23:52 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b4df0980faaa More tabulators ! src/share/classes/java/util/stream/reduce/Tabulators.java From brian.goetz at oracle.com Sat Dec 15 10:44:22 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sat, 15 Dec 2012 18:44:22 +0000 Subject: hg: lambda/lambda/jdk: Eliminate Streamable; rename most .parallel() methods to .parallelStream Message-ID: <20121215184517.EF0874719F@hg.openjdk.java.net> Changeset: e41e14b4470a Author: briangoetz Date: 2012-12-15 13:37 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/e41e14b4470a Eliminate Streamable; rename most .parallel() methods to .parallelStream ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/LinkedHashSet.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedSet.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/stream/ReferencePipeline.java - src/share/classes/java/util/stream/Streamable.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/op/SpinedBuffer.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntSpinedBuffer.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamReuseTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ConcatOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindAnyOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MatchOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/PrimitiveOpsTests.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SliceOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java From brian.goetz at oracle.com Sat Dec 15 14:43:30 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sat, 15 Dec 2012 22:43:30 +0000 Subject: hg: lambda/lambda/jdk: Metafactory support for serialized lambdas, with test case. Can now create, invoke, and serialize, but not deserialize, serializable lambdas. Message-ID: <20121215224421.8FE49471A4@hg.openjdk.java.net> Changeset: 3efe320f209d Author: briangoetz Date: 2012-12-15 17:43 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3efe320f209d Metafactory support for serialized lambdas, with test case. Can now create, invoke, and serialize, but not deserialize, serializable lambdas. ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java ! src/share/classes/java/lang/invoke/LambdaMetafactory.java ! src/share/classes/java/lang/invoke/SerializedLambda.java + test-ng/tests/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java From brian.goetz at oracle.com Sat Dec 15 15:05:58 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sat, 15 Dec 2012 23:05:58 +0000 Subject: hg: lambda/lambda/jdk: More serialization tests Message-ID: <20121215230609.ABDC6471A5@hg.openjdk.java.net> Changeset: 562f136348df Author: briangoetz Date: 2012-12-15 18:05 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/562f136348df More serialization tests ! test-ng/tests/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java From boaznahum at gmail.com Sat Dec 15 16:41:43 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Sun, 16 Dec 2012 02:41:43 +0200 Subject: Mapper factory, overloaded handlers and eraser - no warning from the compiler Message-ID: In Fuctions { private static final Function STRING = String::valueOf; public static Function string() { return (Function) STRING; } } But because of valueOf is overloaded there is no way that the 'correct' method is called, for example char[] data = new char[] {'h', 'e', 'l', 'l', 'o'}; Function vo = Functions.string(); System.out.println( vo.apply(data)); Produces: [C at 11da1f99 But: Function vo = String::valueOf; System.out.println( vo.apply(data)); Produces 'hello' Is just a matter of documentation ? /** * Returns a mapper which performs a mapping from {@code } to it's * string representation. */ And the 'string representation' of char[] is char[].toString() ? ---------------------- More important: ---------------------- static Function string() { return String::valueOf; } The compiler DOES NOT warn you that due to the eraser(?) valueOf(Object) is always called !! Thanks Boaz From brian.goetz at oracle.com Sat Dec 15 17:09:59 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 15 Dec 2012 20:09:59 -0500 Subject: Mapper factory, overloaded handlers and eraser - no warning from the compiler In-Reply-To: References: Message-ID: <50CD1F67.1080507@oracle.com> First let's take method references out of the equation. Your code basically says: private static final Function STRING = (Object o) -> String.valueOf(o); Which is fine, but: you've *already selected an overload* of valueOf. > char[] data = new char[] {'h', 'e', 'l', 'l', 'o'}; > Function vo = Functions.string(); > System.out.println( vo.apply(data)); Now, what you're doing is the exact same thing as: char[] c = ... System.out.println(String.valueOf((Object) c)); Which will also print out [C at blarf. > But: > Function vo = String::valueOf; > System.out.println( vo.apply(data)); > > Produces 'hello' Right. Because you're calling a different method, one that happens to have a similar name. Method references are not references to a method name; they are references to a *specific method*, which may involve overload selection at the time the method ref is constructed. Bottom line is: the string() code is simply broken. > ---------------------- > More important: > ---------------------- > > static Function string() { > return String::valueOf; > } > > The compiler DOES NOT warn you that due to the eraser(?) valueOf(Object) > is always called !! So, you somehow have come to a mental model that says a method reference somehow refers to a family of methods with the same name, and that overload selection is done at invocation time rather than capture time. I could see how one could think that, but that's simply not how method references work. The compiler *will* warn you if it cannot fine a unique valueOf method that is compatible with the signature T -> String. I don't think any sort of warning is warranted or appropriate here. Think about it this way. A method reference is really just shorthand for a lambda: Function lambda = (T t) -> String.valueOf(t); Which under the hood just becomes a method: String lambda$1(T t) { return String.valueOf(t); } Now, when viewed in this form, do you really think a warning is in order that the compiler is selecting a specific overload based on the static bound of T, rather than its dynamic type? From boaznahum at gmail.com Sun Dec 16 09:52:03 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Sun, 16 Dec 2012 19:52:03 +0200 Subject: hg: lambda/lambda/langtools: Enhancement: Add support for static interface methods In-Reply-To: <20121203161153.8067147CE9@hg.openjdk.java.net> References: <20121203161153.8067147CE9@hg.openjdk.java.net> Message-ID: Hi. I'm building lambda/lambda on daily basis. I'm trying to run example with static method interface, adding -Xverify:none, but still getting Exception in thread "main" java.lang.VerifyError: Illegal static method sayHello in interface I1 is this supposed to work ? Thanks Boaz On Mon, Dec 3, 2012 at 6:11 PM, wrote: > Changeset: 67030038d40b > Author: mcimadamore > Date: 2012-12-03 15:32 +0000 > URL: > http://hg.openjdk.java.net/lambda/lambda/langtools/rev/67030038d40b > > Enhancement: Add support for static interface methods > > This patch adds support for static interface methods. > Hiding rules are simpler than those for static class methods, as a static > interface method cannot be inherithed. > > ! src/share/classes/com/sun/tools/javac/code/Flags.java > ! src/share/classes/com/sun/tools/javac/code/Source.java > ! src/share/classes/com/sun/tools/javac/code/Symbol.java > ! src/share/classes/com/sun/tools/javac/comp/Attr.java > ! src/share/classes/com/sun/tools/javac/comp/Check.java > ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java > ! src/share/classes/com/sun/tools/javac/resources/compiler.properties > + test/tools/javac/defaultMethods/hiding/InterfaceMethodHidingTest.java > ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java > ! test/tools/javac/diags/examples.not-yet.txt > > > From forax at univ-mlv.fr Sun Dec 16 11:03:46 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Sun, 16 Dec 2012 20:03:46 +0100 Subject: hg: lambda/lambda/langtools: Enhancement: Add support for static interface methods In-Reply-To: References: <20121203161153.8067147CE9@hg.openjdk.java.net> Message-ID: <50CE1B12.7080508@univ-mlv.fr> On 12/16/2012 06:52 PM, Boaz Nahum wrote: > Hi. > > I'm building lambda/lambda on daily basis. > > I'm trying to run example with static method interface, adding > -Xverify:none, but still getting > > Exception in thread "main" java.lang.VerifyError: Illegal static method > sayHello in interface I1 > > is this supposed to work ? It will work when the VM will support it, currently only the compiler support was pushed. > > Thanks > Boaz R?mi > > > > > On Mon, Dec 3, 2012 at 6:11 PM, wrote: > >> Changeset: 67030038d40b >> Author: mcimadamore >> Date: 2012-12-03 15:32 +0000 >> URL: >> http://hg.openjdk.java.net/lambda/lambda/langtools/rev/67030038d40b >> >> Enhancement: Add support for static interface methods >> >> This patch adds support for static interface methods. >> Hiding rules are simpler than those for static class methods, as a static >> interface method cannot be inherithed. >> >> ! src/share/classes/com/sun/tools/javac/code/Flags.java >> ! src/share/classes/com/sun/tools/javac/code/Source.java >> ! src/share/classes/com/sun/tools/javac/code/Symbol.java >> ! src/share/classes/com/sun/tools/javac/comp/Attr.java >> ! src/share/classes/com/sun/tools/javac/comp/Check.java >> ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java >> ! src/share/classes/com/sun/tools/javac/resources/compiler.properties >> + test/tools/javac/defaultMethods/hiding/InterfaceMethodHidingTest.java >> ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java >> ! test/tools/javac/diags/examples.not-yet.txt >> >> >> From boaznahum at gmail.com Sun Dec 16 11:28:18 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Sun, 16 Dec 2012 21:28:18 +0200 Subject: hg: lambda/lambda/langtools: Enhancement: Add support for static interface methods In-Reply-To: <50CE1B12.7080508@univ-mlv.fr> References: <20121203161153.8067147CE9@hg.openjdk.java.net> <50CE1B12.7080508@univ-mlv.fr> Message-ID: Sorry. I just followed the sugestion " Btw - for those willing to experiment, I noticed that if you try to run code that calls static interface method you get a verifier error because of a verifier glitch (the verifier doesn't like an interface method CP entry on an invokestatic) - so you need to run with -Xverify:none, for now." On Dec 16, 2012 9:07 PM, "Remi Forax" wrote: > On 12/16/2012 06:52 PM, Boaz Nahum wrote: > > Hi. > > > > I'm building lambda/lambda on daily basis. > > > > I'm trying to run example with static method interface, adding > > -Xverify:none, but still getting > > > > Exception in thread "main" java.lang.VerifyError: Illegal static method > > sayHello in interface I1 > > > > is this supposed to work ? > > It will work when the VM will support it, currently only the compiler > support was pushed. > > > > > Thanks > > Boaz > > R?mi > > > > > > > > > > > On Mon, Dec 3, 2012 at 6:11 PM, wrote: > > > >> Changeset: 67030038d40b > >> Author: mcimadamore > >> Date: 2012-12-03 15:32 +0000 > >> URL: > >> http://hg.openjdk.java.net/lambda/lambda/langtools/rev/67030038d40b > >> > >> Enhancement: Add support for static interface methods > >> > >> This patch adds support for static interface methods. > >> Hiding rules are simpler than those for static class methods, as a > static > >> interface method cannot be inherithed. > >> > >> ! src/share/classes/com/sun/tools/javac/code/Flags.java > >> ! src/share/classes/com/sun/tools/javac/code/Source.java > >> ! src/share/classes/com/sun/tools/javac/code/Symbol.java > >> ! src/share/classes/com/sun/tools/javac/comp/Attr.java > >> ! src/share/classes/com/sun/tools/javac/comp/Check.java > >> ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java > >> ! src/share/classes/com/sun/tools/javac/resources/compiler.properties > >> + test/tools/javac/defaultMethods/hiding/InterfaceMethodHidingTest.java > >> ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java > >> ! test/tools/javac/diags/examples.not-yet.txt > >> > >> > >> > > > From david.holmes at oracle.com Sun Dec 16 20:12:31 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Dec 2012 14:12:31 +1000 Subject: signatures that are recorded for default methods In-Reply-To: References: <00C97E54-7649-4FC5-8A59-C5133E4426C2@oracle.com> <50CA2B58.5030103@oracle.com> <50CA4320.40408@oracle.com> <50CA61DA.7050205@oracle.com> <46D348C4-E38A-418E-A1D4-C789B038F078@oracle.com> <50CAC55A.3010602@oracle.com> Message-ID: <50CE9BAF.4090000@oracle.com> On 15/12/2012 1:01 AM, Paul Benedict wrote: > David, forgive me for lousy sentence construction :-) > > There's no way to say "The default implementation does..." and not > have it be part of the interface spec. Whatever the default method > does becomes the stated contract for any other implementation of > OpenJDK. That need not be true and that is exactly what has yet to be determined. The precedent already exists with implementation notes in existing JDK classes. Such notes do not constrain others who wish to provide an implementation of the JDK. David ----- > Paul > > On Fri, Dec 14, 2012 at 12:21 AM, David Holmes wrote: >> Paul, >> >> >> On 14/12/2012 9:46 AM, Paul Benedict wrote: >>> >>> Lance, >>> >>> Good questions. Someone with authority will surely answer, but here's >>> my armchair opinion... >>> >>> If the Javadoc is to specify how the default method executes, than >>> that would naturally infer all default implementations must have a >>> stated contract. You can't document the default execution behavior in >>> the public API and then let a provider switch the behavior. The two go >>> hand-in-hand, imo. >> >> >> I couldn't really make sense of that. :) The method has a contract. The >> "default implementation" has to honor that contract. The question is whether >> how the "default implementation" honors the method contract is required to >> be part of a second contract. >> >> I hope that made sense :) >> >> David >> ----- >> >> >> >>> Paul >>> >>> On Thu, Dec 13, 2012 at 5:30 PM, Lance Andersen - Oracle >>> wrote: >>>> >>>> >>>> On Dec 13, 2012, at 6:16 PM, Leonid Arbuzov wrote: >>>> >>>>> Good point, Joe. >>>>> Those extra assertions for default methods can be checked >>>>> by regular API tests separately from signature tests. >>>> >>>> >>>> I am not clear on this. See the message attached from David which ask a >>>> similar question (from the attached email): >>>> ------------------- >>>> 2. It is not obvious to me that the JDK's choice for a default >>>> implementation has to be _the_ only possible implementation choice. In >>>> many/most cases there will be a very obvious choice, but that doesn't mean >>>> that all suppliers of OpenJDK classes have to be locked in to that choice. >>>> ------------------- >>>> >>>> >>>> If everyone needs to implement the same default implementation then great >>>> the JCK/TCK can test it and IMHO we should have a javadoc tag for this. >>>> >>>> If everyone is free to choose what the default behavior is, then we >>>> cannot test it. >>>> >>>> So has there been a decision WRT the requirements for default methods? >>>> >>>> >>>> Best >>>> Lance >>>>> >>>>> Thanks, >>>>> -leonid >>>>> >>>>> On 12/13/2012 1:05 PM, Joe Darcy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> As with concrete methods on abstract classes, I would expect the >>>>>> specifications of the default methods to often contain text akin to "This >>>>>> default implementation does x, y, and z" since if the method is to be called >>>>>> by subtypes, the self-use patterns in the default method need to be known. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> -Joe >>>>>> >>>>>> On 12/13/2012 11:24 AM, Leonid Arbouzov wrote: >>>>>>> >>>>>>> Hello Lance, >>>>>>> >>>>>>> My understanding would be that the signature test >>>>>>> should check that interface method is marked as default method >>>>>>> but do not track the code in its default body >>>>>>> (assuming that the body is not a part of a spec - API javadoc). >>>>>>> >>>>>>> (I've confirmed that with the signature test developer) >>>>>>> >>>>>>> Thanks, >>>>>>> -leonid >>>>>>> >>>>>>> On 12/6/2012 9:01 AM, Lance Andersen - Oracle wrote: >>>>>>>> >>>>>>>> Folks, >>>>>>>> >>>>>>>> Will the signatures for interfaces that are recorded by the TCKs for >>>>>>>> interfaces record the fact that a method includes a default method? or will >>>>>>>> it just record the method definition? >>>>>>>> >>>>>>>> I am assuming it will, but I know there has been discussion that a >>>>>>>> implementor could choose a different default implementation on one of the >>>>>>>> recent threads that was up for review. >>>>>>>> >>>>>>>> I am still trying to understand what our guidelines are, if any for >>>>>>>> documenting the behavior of the supplied default methods given the javadocs >>>>>>>> are part of the specification for many APIs (and in some case the only >>>>>>>> spec). >>>>>>>> >>>>>>>> Best >>>>>>>> Lance >>>>>>>> >>>>>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>>>>> Oracle Java Engineering >>>>>>>> 1 Network Drive >>>>>>>> Burlington, MA 01803 >>>>>>>> Lance.Andersen at oracle.com >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>>> >>>> >>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >>>> >>>> >>> >> From david.holmes at oracle.com Sun Dec 16 20:18:42 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 17 Dec 2012 14:18:42 +1000 Subject: RFR : CR8004015 : Add parent interfaces and default methods to basic functional interfaces In-Reply-To: <0A9D8113-780C-4BA7-9380-AAD53A0DAA58@oracle.com> References: <99DC2763-ED44-42CA-90F3-04AD07B2846D@oracle.com> <50CAC719.7090308@oracle.com> <0A9D8113-780C-4BA7-9380-AAD53A0DAA58@oracle.com> Message-ID: <50CE9D22.7060108@oracle.com> On 15/12/2012 4:58 AM, Mike Duigou wrote: > > On Dec 13 2012, at 22:28 , David Holmes wrote: > >>> I have added @throws NPE for a number of the default methods. We won't be including @throws NPE in all cases where null is disallowed because when the @throws NPE is declared the API is required to throw NPE in that circumstance. So for cases where the NPE is "naturally" thrown or that aren't performance sensitive we will likely add @throws NPE declarations but for performance sensitive methods we won't be adding explicit null checks to match a @throws NPE specification. There's a tradeoff here in some cases. Please feel free to quibble about specific cases as they occur. :-) >> >> That doesn't make sense to me. The throwing of the NPE is intended to be part of the specification not an implementation choice. Further @param foo non-null, is just as binding on implementations as @throws NPE if foo is null. ??? > > An "@param foo non-null" by itself is not considered normative because it doesn't document what happens when null is passed. So it ends up being advisory only. An "@throws NPE" is considered normative and the implementation must throw in all circumstances described. Aside: that is an interesting interpretation but from whence does it come? It is non-normative by definition because it is incomplete? Or is it just non-normative because it is an @param tag? > (Please bear with the step-by-step nature of the following sample, it's incremental pace is not meant to be insulting--it's a write-up for a general FAQ). If I have a method: But once you add the @throws the advisory of the @param is redundant. Hence to me it is an either/or situation. Further the advisory, being advisory, is useless in my opinion, so not something to use regardless. David ----- > /** > * If the object is visible then write it's string form to the provided PrintStream. > * > * @param bar destination for display > / > public void display(PrintStream bar) { > if(visible) { > bar.write(toString()); > } > } > > This implementation isn't going to work well if "bar" is ever null. So I document that in the "@param bar": > > /** > * If the object is visible then write it's string form to the provided PrintStream. > * > * @param bar destination for display, must be non-null > / > public void display(PrintStream bar) { > if(visible) { > bar.write(toString()); > } > } > > The "@param bar" documentation now says that it must be non-null but doesn't explain what happens if null is passed. Having documented that null shouldn't be passed is helpful but not as helpful as it could be. To specify what happens I must add "@throws NPE": > > /** > * If the object is visible then write it's string form to the provided PrintStream. > * > * @param bar destination for display, must be non-null > * @throws NullPointerException if bar is null > / > public void display(PrintStream bar) { > if(visible) { > bar.write(toString()); > } > } > > This implementation would superficially seem to conform to the contract described in the javadoc. However, when the "if(visible)" conditional is false then no NPE will be thrown. Contract broken. It is required to add an explicit null check on "bar" ie. > > /** > * If the object is visible then write it's string form to the provided PrintStream. > * > * @param bar destination for display, must be non-null > * @throws NullPointerException if bar is null > / > public void display(PrintStream bar) { > Objects.requireNonNull(bar); > if(visible) { > bar.write(toString()); > } > } > > Adding the "Objects.requireNonNull" ensures that the NPE is thrown in all appropriate cases. There is also another alternative: > > /** > * If the object is visible then write it's string form to the provided PrintStream. > * > * @param bar destination for display, must be non-null > * @throws NullPointerException if bar is null and the component is visible. > / > public void display(PrintStream bar) { > if(visible) { > bar.write(toString()); > } > } > > The conditions in which NPE are thrown are amended so that throwing is only required if the component is visible. Documenting the conditions could quickly become complicated if display was a more involved method. At some point it becomes easier to just add an explicit check. It can also be useful to add explicit NPE checks as pre-conditions before a multi-stage operation where a late stage NPE might corrupt the object state. > > In a very few cases an explicit null check might add too much overhead to a performance sensitive method and writing an accurate "@throws NPE" isn't possible (perhaps because of delegation) then the "@throws NPE" should be removed and only the advisory "@param bar ... must be non-null" will have to suffice. > > Mike > >> I think defining the NPE via the @param and @throws is a lose-lose situation: >> >> ! * @param left {@inheritDoc}, must be non-null >> ! * @param right {@inheritDoc}, must be non-null >> ! * @return {@inheritDoc}, always non-null >> ! * @throws NullPointerException if {@code left} or {@code right} is null >> >> You only need one convention. >> >> David >> ----- >> >> >>> Mike > From robert.field at oracle.com Mon Dec 17 02:00:45 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Mon, 17 Dec 2012 10:00:45 +0000 Subject: hg: lambda/lambda/langtools: Partial (all security checks not yet implemented) implementation of $ method. No regressions in existing tests, but otherwise untested -- readResolve is needed. Message-ID: <20121217100048.84157471CA@hg.openjdk.java.net> Changeset: 0a0392566a68 Author: rfield Date: 2012-12-17 01:59 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/0a0392566a68 Partial (all security checks not yet implemented) implementation of $ method. No regressions in existing tests, but otherwise untested -- readResolve is needed. ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/util/Names.java From scolebourne at joda.org Mon Dec 17 02:26:24 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 17 Dec 2012 10:26:24 +0000 Subject: RFR : CR8004015 : Add parent interfaces and default methods to basic functional interfaces In-Reply-To: <50CE9D22.7060108@oracle.com> References: <99DC2763-ED44-42CA-90F3-04AD07B2846D@oracle.com> <50CAC719.7090308@oracle.com> <0A9D8113-780C-4BA7-9380-AAD53A0DAA58@oracle.com> <50CE9D22.7060108@oracle.com> Message-ID: On 17 December 2012 04:18, David Holmes wrote: > On 15/12/2012 4:58 AM, Mike Duigou wrote: >> On Dec 13 2012, at 22:28 , David Holmes wrote: >> >>>> I have added @throws NPE for a number of the default methods. We won't >>>> be including @throws NPE in all cases where null is disallowed because when >>>> the @throws NPE is declared the API is required to throw NPE in that >>>> circumstance. So for cases where the NPE is "naturally" thrown or that >>>> aren't performance sensitive we will likely add @throws NPE declarations but >>>> for performance sensitive methods we won't be adding explicit null checks to >>>> match a @throws NPE specification. There's a tradeoff here in some cases. >>>> Please feel free to quibble about specific cases as they occur. :-) >>> >>> >>> That doesn't make sense to me. The throwing of the NPE is intended to be >>> part of the specification not an implementation choice. Further @param foo >>> non-null, is just as binding on implementations as @throws NPE if foo is >>> null. ??? >> >> >> An "@param foo non-null" by itself is not considered normative because it >> doesn't document what happens when null is passed. So it ends up being >> advisory only. An "@throws NPE" is considered normative and the >> implementation must throw in all circumstances described. > > > Aside: that is an interesting interpretation but from whence does it come? > It is non-normative by definition because it is incomplete? Or is it just > non-normative because it is an @param tag? > > >> (Please bear with the step-by-step nature of the following sample, it's >> incremental pace is not meant to be insulting--it's a write-up for a general >> FAQ). If I have a method: > > > But once you add the @throws the advisory of the @param is redundant. Hence > to me it is an either/or situation. Further the advisory, being advisory, is > useless in my opinion, so not something to use regardless. Mike, I think your write up makes sense. I prefer the @throws NPE to be decalared at package or class level with reference to the use of the "must not be null" or "not null" wording. (whereas specifying all null-behaviour at the package level is something I dislike). David, Part of the issue with only specifying @throws is multi-parameter methods: /** * @param a sdhgsjgv, not null * @param b sdhgsjgv, null treated as blank string * @param c sdhgsjgv, null ignored * @param d sdhgsjgv, not null */ void process(String a, String b, String c, String d) { ... } Here, there are a combination of possibilities for behaviour. An @throws would have to reference parameters a and d by name, and would specify nothing about b or c, thus b and c would still need specifying somewhere else, most obviously the @param. Referencing a and d by name is also far harder for tooling to find (yes I'm aware of the 305/308 annotations but they don't seem to be being used). Looking for a specific "not null" or "must not be null" string is easy for other languages to scan for (ie Fantom/Kotlin/Ceylon). In other words, in the bigger picture of a general coding standard, I think the example above is far more consistent and understandable. Stephen From paul.sandoz at oracle.com Mon Dec 17 03:15:08 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 17 Dec 2012 11:15:08 +0000 Subject: hg: lambda/lambda/jdk: Depth first seatch for leaf nodes when iterating on a ConcNode. Message-ID: <20121217111532.EA941471CC@hg.openjdk.java.net> Changeset: 8075d7fad8e9 Author: psandoz Date: 2012-12-17 12:14 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8075d7fad8e9 Depth first seatch for leaf nodes when iterating on a ConcNode. This avoids lots of wrapping and enables forEach optimization. ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/primitive/PrimitiveNodes.java From aleksey.shipilev at oracle.com Mon Dec 17 06:07:45 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 17 Dec 2012 18:07:45 +0400 Subject: FJP update Message-ID: <50CF2731.8030603@oracle.com> Hi, I'd like to push this update from JSR166 repo to lambda/lambda: http://shipilev.net/pub/jdk/lambda/20121217-fjp-update-1.patch.gz This fix contains the bugfix for functional regression in FJP. Thanks, -Aleksey. From brian.goetz at oracle.com Mon Dec 17 07:15:47 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 17 Dec 2012 10:15:47 -0500 Subject: FJP update In-Reply-To: <50CF2731.8030603@oracle.com> References: <50CF2731.8030603@oracle.com> Message-ID: <50CF3723.7000101@oracle.com> Pushed. On 12/17/2012 9:07 AM, Aleksey Shipilev wrote: > Hi, > > I'd like to push this update from JSR166 repo to lambda/lambda: > http://shipilev.net/pub/jdk/lambda/20121217-fjp-update-1.patch.gz > > This fix contains the bugfix for functional regression in FJP. > > Thanks, > -Aleksey. > From brian.goetz at oracle.com Mon Dec 17 07:16:04 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 17 Dec 2012 15:16:04 +0000 Subject: hg: lambda/lambda/jdk: Bugfixes for functional regressions in ForkJoinPool. Message-ID: <20121217151626.C57EF471D2@hg.openjdk.java.net> Changeset: 050978332861 Author: briangoetz Date: 2012-12-17 10:15 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/050978332861 Bugfixes for functional regressions in ForkJoinPool. Contributed-by: aleksey.shipilev at oracle.com ! src/share/classes/java/util/concurrent/CountedCompleter.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java From aleksey.shipilev at oracle.com Mon Dec 17 07:46:59 2012 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 17 Dec 2012 19:46:59 +0400 Subject: hg: lambda/lambda/jdk: Bugfixes for functional regressions in ForkJoinPool. In-Reply-To: <20121217151626.C57EF471D2@hg.openjdk.java.net> References: <20121217151626.C57EF471D2@hg.openjdk.java.net> Message-ID: <50CF3E73.2070500@oracle.com> On 12/17/2012 07:16 PM, brian.goetz at oracle.com wrote: > Changeset: 050978332861 > Author: briangoetz > Date: 2012-12-17 10:15 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/050978332861 > > Bugfixes for functional regressions in ForkJoinPool. > Contributed-by: aleksey.shipilev at oracle.com Obnoxious note, should be: Contributed-by: dl, shade -Aleksey. From maurizio.cimadamore at oracle.com Mon Dec 17 07:49:27 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 17 Dec 2012 15:49:27 +0000 Subject: hg: lambda/lambda/langtools: Enhancement: Implement overload resolution as per latest spec EDR Message-ID: <20121217154930.67630471D4@hg.openjdk.java.net> Changeset: 1f2fbcd0de7e Author: mcimadamore Date: 2012-12-17 15:36 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/1f2fbcd0de7e Enhancement: Implement overload resolution as per latest spec EDR *) Restructure DeferredAttr to allow pluggable deferred type completers *) Add 'potentially applicable' phase for stuck arguments as a pluggable deferred completer *) Delay instantiation of stuck ivars until after overload resolution *) Restructure method check code to allow pluggable checkers *) Implement new structural most specific routine as pluggable method check *) Flatten AmbiguityError class *) Delay merging of abstract ambiguous signatures until end of overload resolution *) Lambda/method reference type-checking always use loose check context ! src/share/classes/com/sun/tools/javac/code/Source.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/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/GraphInfer.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/LegacyInfer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! 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/TreeInfo.java ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/CyclicInference.java - test/tools/javac/diags/examples/InferredDoNotConformToLower.java - test/tools/javac/diags/examples/NoUniqueMaximalInstance.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/generics/diamond/T6939780.out ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/neg/Neg10.java ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/lambda/MethodReference25.java + test/tools/javac/lambda/MethodReference25.out ! test/tools/javac/lambda/MethodReference26.java - test/tools/javac/lambda/MethodReference26.out ! test/tools/javac/lambda/MethodReference43.java ! test/tools/javac/lambda/TargetType01.java + test/tools/javac/lambda/TargetType01.out ! test/tools/javac/lambda/TargetType06.java ! test/tools/javac/lambda/TargetType10.out ! test/tools/javac/lambda/TargetType11.java ! test/tools/javac/lambda/TargetType14.out ! test/tools/javac/lambda/TargetType21.java ! test/tools/javac/lambda/TargetType21.out ! test/tools/javac/lambda/TargetType26.out ! test/tools/javac/lambda/TargetType27.out ! test/tools/javac/lambda/TargetType28.out ! test/tools/javac/lambda/TargetType39.out ! test/tools/javac/lambda/TargetType45.java - test/tools/javac/lambda/TargetType45.out ! test/tools/javac/lambda/TargetType50.out + test/tools/javac/lambda/TargetType51.java ! test/tools/javac/lambda/VoidCompatibility.java - test/tools/javac/lambda/VoidCompatibility.out ! test/tools/javac/lambda/lambdaExpression/SamConversionComboTest.java ! test/tools/javac/lambda/methodReference/SamConversion.java ! test/tools/javac/lambda/methodReference/SamConversionComboTest.java ! test/tools/javac/lambda/typeInference/InferenceTest_neg5.out ! test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java From georgiy.rakov at oracle.com Mon Dec 17 08:30:00 2012 From: georgiy.rakov at oracle.com (Georgiy Rakov) Date: Mon, 17 Dec 2012 20:30:00 +0400 Subject: VM issue: java.lang.VerifyError Message-ID: <50CF4888.8090508@oracle.com> Hello, while developing we encountered java.lang.VerifyError to be thrown at run-time. Build 68 of December 9 caused this problem; platform: Windows x64. The minimized code is attached. It causes the following output: Exception in thread "main" java.lang.VerifyError: Bad type on operand stack Exception Details: Location: Factory3.create(LMyClass;)LFactory3; @13: invokedynamic Reason: Type 'MyClass' (current frame, stack[3]) is not assignable to 'Factory3' Current Frame: bci: @13 flags: { } locals: { 'MyClass' } stack: { uninitialized 0, uninitialized 0, 'MyClass2', 'MyClass' } Bytecode: 0000000: bb00 0159 bb00 0259 2ab7 0003 2aba 0004 0000010: 0000 b700 05b0 at VmIssue$1.lambda$0(VmIssue.java:6) at VmIssue$1$$Lambda$2.myCreate(Unknown Source) at VmIssue.lambda$1(VmIssue.java:9) at VmIssue$$Lambda$1.add(Unknown Source) at VmIssue$1.create(VmIssue.java:6) at VmIssue.main(VmIssue.java:8) It looks like bug in VM. Please confirm if it really is. Thanks, Georgiy. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: VmIssue.java Url: http://mail.openjdk.java.net/pipermail/lambda-dev/attachments/20121217/03b5a892/VmIssue.java From scolebourne at joda.org Mon Dec 17 09:10:41 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 17 Dec 2012 17:10:41 +0000 Subject: Static methods on interfaces Message-ID: Can we (JSR-310 and more generally) rely on static methods in interfaces being in JDK8? It affects a design decision currently in progress ;-) http://mail.openjdk.java.net/pipermail/lambda-dev/2012-December/006969.html Also, can we assume that static methods are in not inherited by implementors (unlike static constants on interfaces)? Stephen From maurizio.cimadamore at oracle.com Mon Dec 17 09:15:03 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 17 Dec 2012 17:15:03 +0000 Subject: Static methods on interfaces In-Reply-To: References: Message-ID: <50CF5317.1010100@oracle.com> On 17/12/12 17:10, Stephen Colebourne wrote: > Can we (JSR-310 and more generally) rely on static methods in > interfaces being in JDK8? It affects a design decision currently in > progress ;-) > > http://mail.openjdk.java.net/pipermail/lambda-dev/2012-December/006969.html > > Also, can we assume that static methods are in not inherited by > implementors (unlike static constants on interfaces)? > > Stephen > Did you mean to post on lambda-spec? Maurizio From brian.goetz at oracle.com Mon Dec 17 09:20:15 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 17 Dec 2012 12:20:15 -0500 Subject: Static methods on interfaces In-Reply-To: References: Message-ID: <50CF544F.70707@oracle.com> This is the plan of record. If you're looking for some sort of yacht-collateralized guarantee, though, we don't offer those. More strongly, the only way to invoke a static method on an interface is: DeclaringInterfaceName.methodName(args) Not subinterfaces, not subclasses, not instances. On 12/17/2012 12:10 PM, Stephen Colebourne wrote: > Can we (JSR-310 and more generally) rely on static methods in > interfaces being in JDK8? It affects a design decision currently in > progress ;-) > > http://mail.openjdk.java.net/pipermail/lambda-dev/2012-December/006969.html > > Also, can we assume that static methods are in not inherited by > implementors (unlike static constants on interfaces)? > > Stephen > From scolebourne at joda.org Mon Dec 17 09:25:10 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 17 Dec 2012 17:25:10 +0000 Subject: Static methods on interfaces In-Reply-To: <50CF544F.70707@oracle.com> References: <50CF544F.70707@oracle.com> Message-ID: Thanks. The invocation guarantee looks good. Stephen On 17 December 2012 17:20, Brian Goetz wrote: > This is the plan of record. If you're looking for some sort of > yacht-collateralized guarantee, though, we don't offer those. > > More strongly, the only way to invoke a static method on an interface is: > > DeclaringInterfaceName.methodName(args) > > Not subinterfaces, not subclasses, not instances. > > > On 12/17/2012 12:10 PM, Stephen Colebourne wrote: >> >> Can we (JSR-310 and more generally) rely on static methods in >> interfaces being in JDK8? It affects a design decision currently in >> progress ;-) >> >> >> http://mail.openjdk.java.net/pipermail/lambda-dev/2012-December/006969.html >> >> Also, can we assume that static methods are in not inherited by >> implementors (unlike static constants on interfaces)? >> >> Stephen >> > From maurizio.cimadamore at oracle.com Mon Dec 17 09:35:55 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 17 Dec 2012 17:35:55 +0000 Subject: Static methods on interfaces In-Reply-To: References: <50CF544F.70707@oracle.com> Message-ID: <50CF57FB.3010709@oracle.com> On 17/12/12 17:25, Stephen Colebourne wrote: > Thanks. The invocation guarantee looks good. > Stephen Note: the compiler is currently less strict, so it allows non-type qualifiers for static interface method calls. Maurizio > > On 17 December 2012 17:20, Brian Goetz wrote: >> This is the plan of record. If you're looking for some sort of >> yacht-collateralized guarantee, though, we don't offer those. >> >> More strongly, the only way to invoke a static method on an interface is: >> >> DeclaringInterfaceName.methodName(args) >> >> Not subinterfaces, not subclasses, not instances. >> >> >> On 12/17/2012 12:10 PM, Stephen Colebourne wrote: >>> Can we (JSR-310 and more generally) rely on static methods in >>> interfaces being in JDK8? It affects a design decision currently in >>> progress ;-) >>> >>> >>> http://mail.openjdk.java.net/pipermail/lambda-dev/2012-December/006969.html >>> >>> Also, can we assume that static methods are in not inherited by >>> implementors (unlike static constants on interfaces)? >>> >>> Stephen >>> From zhong.j.yu at gmail.com Mon Dec 17 09:49:13 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Mon, 17 Dec 2012 11:49:13 -0600 Subject: Static methods on interfaces In-Reply-To: <50CF544F.70707@oracle.com> References: <50CF544F.70707@oracle.com> Message-ID: On Mon, Dec 17, 2012 at 11:20 AM, Brian Goetz wrote: > This is the plan of record. If you're looking for some sort of > yacht-collateralized guarantee, though, we don't offer those. > > More strongly, the only way to invoke a static method on an interface is: > > DeclaringInterfaceName.methodName(args) > > Not subinterfaces, not subclasses, not instances. what about import static? > > On 12/17/2012 12:10 PM, Stephen Colebourne wrote: >> Can we (JSR-310 and more generally) rely on static methods in >> interfaces being in JDK8? It affects a design decision currently in >> progress ;-) >> >> http://mail.openjdk.java.net/pipermail/lambda-dev/2012-December/006969.html >> >> Also, can we assume that static methods are in not inherited by >> implementors (unlike static constants on interfaces)? >> >> Stephen >> > From forax at univ-mlv.fr Mon Dec 17 09:51:59 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 17 Dec 2012 18:51:59 +0100 Subject: Static methods on interfaces In-Reply-To: References: <50CF544F.70707@oracle.com> Message-ID: <50CF5BBF.7040601@univ-mlv.fr> On 12/17/2012 06:49 PM, Zhong Yu wrote: > On Mon, Dec 17, 2012 at 11:20 AM, Brian Goetz wrote: >> This is the plan of record. If you're looking for some sort of >> yacht-collateralized guarantee, though, we don't offer those. >> >> More strongly, the only way to invoke a static method on an interface is: >> >> DeclaringInterfaceName.methodName(args) >> >> Not subinterfaces, not subclasses, not instances. > what about import static? works if you 'static import' the exact interface that declare the static method. R?mi > >> On 12/17/2012 12:10 PM, Stephen Colebourne wrote: >>> Can we (JSR-310 and more generally) rely on static methods in >>> interfaces being in JDK8? It affects a design decision currently in >>> progress ;-) >>> >>> http://mail.openjdk.java.net/pipermail/lambda-dev/2012-December/006969.html >>> >>> Also, can we assume that static methods are in not inherited by >>> implementors (unlike static constants on interfaces)? >>> >>> Stephen >>> From maurizio.cimadamore at oracle.com Mon Dec 17 10:02:26 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 17 Dec 2012 18:02:26 +0000 Subject: hg: lambda/lambda/langtools: Enhancement: Add experimental support for private (instance) interface methods Message-ID: <20121217180229.4EF19471E1@hg.openjdk.java.net> Changeset: 4014132b136e Author: mcimadamore Date: 2012-12-17 17:53 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/4014132b136e Enhancement: Add experimental support for private (instance) interface methods Note: there's no JVM support for this feature for the time being. Some examples might be made to work using -Xverify:none. ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/defaultMethods/private/Private01.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java ! test/tools/javac/diags/examples.not-yet.txt From robert.field at oracle.com Mon Dec 17 18:51:29 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Tue, 18 Dec 2012 02:51:29 +0000 Subject: hg: lambda/lambda/langtools: Fix lambda serialization so that SerializedLambdaTest works (still imcomplete). Also, guard $ so that it is only generated in serializable cases. Message-ID: <20121218025135.D10C247202@hg.openjdk.java.net> Changeset: b11f5172a066 Author: rfield Date: 2012-12-17 18:51 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/b11f5172a066 Fix lambda serialization so that SerializedLambdaTest works (still imcomplete). Also, guard $ so that it is only generated in serializable cases. ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java From Anna.Kozlova at jetbrains.com Tue Dec 18 03:38:02 2012 From: Anna.Kozlova at jetbrains.com (Anna Kozlova) Date: Tue, 18 Dec 2012 12:38:02 +0100 Subject: execution fails with IncompatibleClassChangeError Message-ID: <00a001cddd14$23d5a1e0$6b80e5a0$@Kozlova@jetbrains.com> Hello, Running the following class {code} public class FooBar { private static final class Bar { private Bar() { } } private interface I { Bar create(); } static void foo(I intf) {} public static void main(String[] args) throws Exception { foo(Bar::new); } } {code} fails with Exception in thread "main" java.lang.IncompatibleClassChangeError at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa tives.java:383) at p.FooBar.main(FooBar.java:18) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:43) at java.lang.reflect.Method.invoke(Method.java:474) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) Caused by: java.lang.IllegalAccessException: member is private: p.FooBar$Bar.()void/invokeSpecial, from p.FooBar at java.lang.invoke.MemberName.makeAccessException(MemberName.java:732) at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:1135) at java.lang.invoke.MethodHandles$Lookup.getDirectConstructor(MethodHandles.jav a:1243) at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles .java:1270) at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa tives.java:381) ... 6 more If I convert method reference to lambda expression or anonymous class everything works correctly. Checked with b68. Thank you Anna From maurizio.cimadamore at oracle.com Tue Dec 18 04:08:54 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 18 Dec 2012 12:08:54 +0000 Subject: execution fails with IncompatibleClassChangeError In-Reply-To: <00a001cddd14$23d5a1e0$6b80e5a0$@Kozlova@jetbrains.com> References: <00a001cddd14$23d5a1e0$6b80e5a0$@Kozlova@jetbrains.com> Message-ID: <50D05CD6.2040506@oracle.com> Thanks for the report. We are aware of the issue and working on a fix. Maurizio On 18/12/12 11:38, Anna Kozlova wrote: > Hello, > > > > Running the following class > > {code} > > public class FooBar { > > private static final class Bar { > > private Bar() { > > } > > } > > > > private interface I { > > Bar create(); > > } > > > > static void foo(I intf) {} > > > > public static void main(String[] args) throws Exception { > > foo(Bar::new); > > } > > } > > {code} > > > > fails with > > Exception in thread "main" java.lang.IncompatibleClassChangeError > > at > java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa > tives.java:383) > > at p.FooBar.main(FooBar.java:18) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57 > ) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl > .java:43) > > at java.lang.reflect.Method.invoke(Method.java:474) > > at > com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > > Caused by: java.lang.IllegalAccessException: member is private: > p.FooBar$Bar.()void/invokeSpecial, from p.FooBar > > at > java.lang.invoke.MemberName.makeAccessException(MemberName.java:732) > > at > java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:1135) > > at > java.lang.invoke.MethodHandles$Lookup.getDirectConstructor(MethodHandles.jav > a:1243) > > at > java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles > .java:1270) > > at > java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa > tives.java:381) > > ... 6 more > > > > If I convert method reference to lambda expression or anonymous class > everything works correctly. Checked with b68. > > > > Thank you > Anna > > > > From brian.goetz at oracle.com Tue Dec 18 07:51:52 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 18 Dec 2012 10:51:52 -0500 Subject: execution fails with IncompatibleClassChangeError In-Reply-To: <00a001cddd14$23d5a1e0$6b80e5a0$@Kozlova@jetbrains.com> References: <00a001cddd14$23d5a1e0$6b80e5a0$@Kozlova@jetbrains.com> Message-ID: <50D09118.2060605@oracle.com> Yes, this is a known bug with constructor refs to private nested classes. We are currently trying to figure out whether the solution needs to come from the compiler or the VM. (In the meantime, you can make the Bar constructor but not class public, which should get you past your current problem without opening additional security holes.) On 12/18/2012 6:38 AM, Anna Kozlova wrote: > Hello, > > > > Running the following class > > {code} > > public class FooBar { > > private static final class Bar { > > private Bar() { > > } > > } > > > > private interface I { > > Bar create(); > > } > > > > static void foo(I intf) {} > > > > public static void main(String[] args) throws Exception { > > foo(Bar::new); > > } > > } > > {code} > > > > fails with > > Exception in thread "main" java.lang.IncompatibleClassChangeError > > at > java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa > tives.java:383) > > at p.FooBar.main(FooBar.java:18) > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57 > ) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl > .java:43) > > at java.lang.reflect.Method.invoke(Method.java:474) > > at > com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) > > Caused by: java.lang.IllegalAccessException: member is private: > p.FooBar$Bar.()void/invokeSpecial, from p.FooBar > > at > java.lang.invoke.MemberName.makeAccessException(MemberName.java:732) > > at > java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:1135) > > at > java.lang.invoke.MethodHandles$Lookup.getDirectConstructor(MethodHandles.jav > a:1243) > > at > java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles > .java:1270) > > at > java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa > tives.java:381) > > ... 6 more > > > > If I convert method reference to lambda expression or anonymous class > everything works correctly. Checked with b68. > > > > Thank you > Anna > > > > From maurizio.cimadamore at oracle.com Tue Dec 18 08:14:19 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 18 Dec 2012 16:14:19 +0000 Subject: execution fails with IncompatibleClassChangeError In-Reply-To: <50D09118.2060605@oracle.com> References: <00a001cddd14$23d5a1e0$6b80e5a0$@Kozlova@jetbrains.com> <50D09118.2060605@oracle.com> Message-ID: <50D0965B.7090106@oracle.com> On 18/12/12 15:51, Brian Goetz wrote: > Yes, this is a known bug with constructor refs to private nested > classes. We are currently trying to figure out whether the solution > needs to come from the compiler or the VM. (In the meantime, you can > make the Bar constructor but not class public, which should get you past > your current problem without opening additional security holes.) I think that, since this is a bug, there's no rush to get a fix in while we are figuring out what's the better way to fix it. If the outcome of the discussion is that we'll have to change the compiler, we'll do that when the time comes. It doesn't seem a super common issue anyway. Maurizio > > On 12/18/2012 6:38 AM, Anna Kozlova wrote: >> Hello, >> >> >> >> Running the following class >> >> {code} >> >> public class FooBar { >> >> private static final class Bar { >> >> private Bar() { >> >> } >> >> } >> >> >> >> private interface I { >> >> Bar create(); >> >> } >> >> >> >> static void foo(I intf) {} >> >> >> >> public static void main(String[] args) throws Exception { >> >> foo(Bar::new); >> >> } >> >> } >> >> {code} >> >> >> >> fails with >> >> Exception in thread "main" java.lang.IncompatibleClassChangeError >> >> at >> java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa >> tives.java:383) >> >> at p.FooBar.main(FooBar.java:18) >> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57 >> ) >> >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl >> .java:43) >> >> at java.lang.reflect.Method.invoke(Method.java:474) >> >> at >> com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) >> >> Caused by: java.lang.IllegalAccessException: member is private: >> p.FooBar$Bar.()void/invokeSpecial, from p.FooBar >> >> at >> java.lang.invoke.MemberName.makeAccessException(MemberName.java:732) >> >> at >> java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:1135) >> >> at >> java.lang.invoke.MethodHandles$Lookup.getDirectConstructor(MethodHandles.jav >> a:1243) >> >> at >> java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles >> .java:1270) >> >> at >> java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa >> tives.java:381) >> >> ... 6 more >> >> >> >> If I convert method reference to lambda expression or anonymous class >> everything works correctly. Checked with b68. >> >> >> >> Thank you >> Anna >> >> >> >> From forax at univ-mlv.fr Tue Dec 18 08:39:08 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 18 Dec 2012 17:39:08 +0100 Subject: execution fails with IncompatibleClassChangeError In-Reply-To: <50D05CD6.2040506@oracle.com> References: <00a001cddd14$23d5a1e0$6b80e5a0$@Kozlova@jetbrains.com> <50D05CD6.2040506@oracle.com> Message-ID: <50D09C2C.1060001@univ-mlv.fr> On 12/18/2012 01:08 PM, Maurizio Cimadamore wrote: > Thanks for the report. We are aware of the issue and working on a fix. yes, the compiler needs to generate an accessor for it. R?mi > > Maurizio > > On 18/12/12 11:38, Anna Kozlova wrote: >> Hello, >> >> >> >> Running the following class >> >> {code} >> >> public class FooBar { >> >> private static final class Bar { >> >> private Bar() { >> >> } >> >> } >> >> >> >> private interface I { >> >> Bar create(); >> >> } >> >> >> >> static void foo(I intf) {} >> >> >> >> public static void main(String[] args) throws Exception { >> >> foo(Bar::new); >> >> } >> >> } >> >> {code} >> >> >> >> fails with >> >> Exception in thread "main" java.lang.IncompatibleClassChangeError >> >> at >> java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa >> tives.java:383) >> >> at p.FooBar.main(FooBar.java:18) >> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57 >> ) >> >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl >> .java:43) >> >> at java.lang.reflect.Method.invoke(Method.java:474) >> >> at >> com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) >> >> Caused by: java.lang.IllegalAccessException: member is private: >> p.FooBar$Bar.()void/invokeSpecial, from p.FooBar >> >> at >> java.lang.invoke.MemberName.makeAccessException(MemberName.java:732) >> >> at >> java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:1135) >> >> at >> java.lang.invoke.MethodHandles$Lookup.getDirectConstructor(MethodHandles.jav >> a:1243) >> >> at >> java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles >> .java:1270) >> >> at >> java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa >> tives.java:381) >> >> ... 6 more >> >> >> >> If I convert method reference to lambda expression or anonymous class >> everything works correctly. Checked with b68. >> >> >> >> Thank you >> Anna >> >> >> >> > From forax at univ-mlv.fr Tue Dec 18 08:54:38 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 18 Dec 2012 17:54:38 +0100 Subject: execution fails with IncompatibleClassChangeError In-Reply-To: <50D0965B.7090106@oracle.com> References: <00a001cddd14$23d5a1e0$6b80e5a0$@Kozlova@jetbrains.com> <50D09118.2060605@oracle.com> <50D0965B.7090106@oracle.com> Message-ID: <50D09FCE.1080206@univ-mlv.fr> On 12/18/2012 05:14 PM, Maurizio Cimadamore wrote: > On 18/12/12 15:51, Brian Goetz wrote: >> Yes, this is a known bug with constructor refs to private nested >> classes. We are currently trying to figure out whether the solution >> needs to come from the compiler or the VM. (In the meantime, you can >> make the Bar constructor but not class public, which should get you past >> your current problem without opening additional security holes.) > I think that, since this is a bug, there's no rush to get a fix in while > we are figuring out what's the better way to fix it. If the outcome of > the discussion is that we'll have to change the compiler, we'll do that > when the time comes. It doesn't seem a super common issue anyway. The root cause of this bug is the infamous 4071957 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957 and to make a long story short, the EG of JSR 292 has decided to align the semantics of method handles on the reflection API on that subject. > > Maurizio R?mi >> On 12/18/2012 6:38 AM, Anna Kozlova wrote: >>> Hello, >>> >>> >>> >>> Running the following class >>> >>> {code} >>> >>> public class FooBar { >>> >>> private static final class Bar { >>> >>> private Bar() { >>> >>> } >>> >>> } >>> >>> >>> >>> private interface I { >>> >>> Bar create(); >>> >>> } >>> >>> >>> >>> static void foo(I intf) {} >>> >>> >>> >>> public static void main(String[] args) throws Exception { >>> >>> foo(Bar::new); >>> >>> } >>> >>> } >>> >>> {code} >>> >>> >>> >>> fails with >>> >>> Exception in thread "main" java.lang.IncompatibleClassChangeError >>> >>> at >>> java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa >>> tives.java:383) >>> >>> at p.FooBar.main(FooBar.java:18) >>> >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>> Method) >>> >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57 >>> ) >>> >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl >>> .java:43) >>> >>> at java.lang.reflect.Method.invoke(Method.java:474) >>> >>> at >>> com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) >>> >>> Caused by: java.lang.IllegalAccessException: member is private: >>> p.FooBar$Bar.()void/invokeSpecial, from p.FooBar >>> >>> at >>> java.lang.invoke.MemberName.makeAccessException(MemberName.java:732) >>> >>> at >>> java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:1135) >>> >>> at >>> java.lang.invoke.MethodHandles$Lookup.getDirectConstructor(MethodHandles.jav >>> a:1243) >>> >>> at >>> java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles >>> .java:1270) >>> >>> at >>> java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa >>> tives.java:381) >>> >>> ... 6 more >>> >>> >>> >>> If I convert method reference to lambda expression or anonymous class >>> everything works correctly. Checked with b68. >>> >>> >>> >>> Thank you >>> Anna >>> >>> >>> >>> > From brian.goetz at oracle.com Tue Dec 18 08:59:30 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 18 Dec 2012 11:59:30 -0500 Subject: execution fails with IncompatibleClassChangeError In-Reply-To: <50D09C2C.1060001@univ-mlv.fr> References: <00a001cddd14$23d5a1e0$6b80e5a0$@Kozlova@jetbrains.com> <50D05CD6.2040506@oracle.com> <50D09C2C.1060001@univ-mlv.fr> Message-ID: <50D0A0F2.6010706@oracle.com> Easier would be to do what we do for other kinds of method refs that can't cleanly be implemented as an MH (such as defender super calls), which is to desugar to a method (basically turn the MR back into its equivalent lambda.) Since you asked... :) The underlying problem comes from the 292 spec, which nest-mate accessibility for MHs is different from the rules in the source language. 292 could fix this too...hint... On 12/18/2012 11:39 AM, Remi Forax wrote: > On 12/18/2012 01:08 PM, Maurizio Cimadamore wrote: >> Thanks for the report. We are aware of the issue and working on a fix. > > yes, the compiler needs to generate an accessor for it. > > R?mi > >> >> Maurizio >> >> On 18/12/12 11:38, Anna Kozlova wrote: >>> Hello, >>> >>> >>> >>> Running the following class >>> >>> {code} >>> >>> public class FooBar { >>> >>> private static final class Bar { >>> >>> private Bar() { >>> >>> } >>> >>> } >>> >>> >>> >>> private interface I { >>> >>> Bar create(); >>> >>> } >>> >>> >>> >>> static void foo(I intf) {} >>> >>> >>> >>> public static void main(String[] args) throws Exception { >>> >>> foo(Bar::new); >>> >>> } >>> >>> } >>> >>> {code} >>> >>> >>> >>> fails with >>> >>> Exception in thread "main" java.lang.IncompatibleClassChangeError >>> >>> at >>> java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa >>> tives.java:383) >>> >>> at p.FooBar.main(FooBar.java:18) >>> >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>> Method) >>> >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57 >>> ) >>> >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl >>> .java:43) >>> >>> at java.lang.reflect.Method.invoke(Method.java:474) >>> >>> at >>> com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) >>> >>> Caused by: java.lang.IllegalAccessException: member is private: >>> p.FooBar$Bar.()void/invokeSpecial, from p.FooBar >>> >>> at >>> java.lang.invoke.MemberName.makeAccessException(MemberName.java:732) >>> >>> at >>> java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:1135) >>> >>> at >>> java.lang.invoke.MethodHandles$Lookup.getDirectConstructor(MethodHandles.jav >>> a:1243) >>> >>> at >>> java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles >>> .java:1270) >>> >>> at >>> java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa >>> tives.java:381) >>> >>> ... 6 more >>> >>> >>> >>> If I convert method reference to lambda expression or anonymous class >>> everything works correctly. Checked with b68. >>> >>> >>> >>> Thank you >>> Anna >>> >>> >>> >>> >> > > From forax at univ-mlv.fr Tue Dec 18 09:00:13 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 18 Dec 2012 18:00:13 +0100 Subject: execution fails with IncompatibleClassChangeError In-Reply-To: <50D0A0F2.6010706@oracle.com> References: <00a001cddd14$23d5a1e0$6b80e5a0$@Kozlova@jetbrains.com> <50D05CD6.2040506@oracle.com> <50D09C2C.1060001@univ-mlv.fr> <50D0A0F2.6010706@oracle.com> Message-ID: <50D0A11D.6040001@univ-mlv.fr> On 12/18/2012 05:59 PM, Brian Goetz wrote: > Easier would be to do what we do for other kinds of method refs that > can't cleanly be implemented as an MH (such as defender super calls), > which is to desugar to a method (basically turn the MR back into its > equivalent lambda.) > > Since you asked... :) The underlying problem comes from the 292 spec, > which nest-mate accessibility for MHs is different from the rules in > the source language. 292 could fix this too...hint... yes, I know, we have decided to not fix it. The 'Right' way to fix that is to have a real class format that embodies several classes in the same classfile. R?mi (I hate when the mailing list is lagging). > > On 12/18/2012 11:39 AM, Remi Forax wrote: >> On 12/18/2012 01:08 PM, Maurizio Cimadamore wrote: >>> Thanks for the report. We are aware of the issue and working on a fix. >> >> yes, the compiler needs to generate an accessor for it. >> >> R?mi >> >>> >>> Maurizio >>> >>> On 18/12/12 11:38, Anna Kozlova wrote: >>>> Hello, >>>> >>>> >>>> >>>> Running the following class >>>> >>>> {code} >>>> >>>> public class FooBar { >>>> >>>> private static final class Bar { >>>> >>>> private Bar() { >>>> >>>> } >>>> >>>> } >>>> >>>> >>>> >>>> private interface I { >>>> >>>> Bar create(); >>>> >>>> } >>>> >>>> >>>> >>>> static void foo(I intf) {} >>>> >>>> >>>> >>>> public static void main(String[] args) throws Exception { >>>> >>>> foo(Bar::new); >>>> >>>> } >>>> >>>> } >>>> >>>> {code} >>>> >>>> >>>> >>>> fails with >>>> >>>> Exception in thread "main" java.lang.IncompatibleClassChangeError >>>> >>>> at >>>> java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa >>>> >>>> tives.java:383) >>>> >>>> at p.FooBar.main(FooBar.java:18) >>>> >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>>> Method) >>>> >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57 >>>> >>>> ) >>>> >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl >>>> >>>> .java:43) >>>> >>>> at java.lang.reflect.Method.invoke(Method.java:474) >>>> >>>> at >>>> com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) >>>> >>>> Caused by: java.lang.IllegalAccessException: member is private: >>>> p.FooBar$Bar.()void/invokeSpecial, from p.FooBar >>>> >>>> at >>>> java.lang.invoke.MemberName.makeAccessException(MemberName.java:732) >>>> >>>> at >>>> java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:1135) >>>> >>>> >>>> at >>>> java.lang.invoke.MethodHandles$Lookup.getDirectConstructor(MethodHandles.jav >>>> >>>> a:1243) >>>> >>>> at >>>> java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles >>>> >>>> .java:1270) >>>> >>>> at >>>> java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa >>>> >>>> tives.java:381) >>>> >>>> ... 6 more >>>> >>>> >>>> >>>> If I convert method reference to lambda expression or anonymous class >>>> everything works correctly. Checked with b68. >>>> >>>> >>>> >>>> Thank you >>>> Anna >>>> >>>> >>>> >>>> >>> >> >> From maurizio.cimadamore at oracle.com Tue Dec 18 09:32:59 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 18 Dec 2012 17:32:59 +0000 Subject: execution fails with IncompatibleClassChangeError In-Reply-To: <50D09FCE.1080206@univ-mlv.fr> References: <00a001cddd14$23d5a1e0$6b80e5a0$@Kozlova@jetbrains.com> <50D09118.2060605@oracle.com> <50D0965B.7090106@oracle.com> <50D09FCE.1080206@univ-mlv.fr> Message-ID: <50D0A8CB.3030900@oracle.com> On 18/12/12 16:54, Remi Forax wrote: > On 12/18/2012 05:14 PM, Maurizio Cimadamore wrote: >> On 18/12/12 15:51, Brian Goetz wrote: >>> Yes, this is a known bug with constructor refs to private nested >>> classes. We are currently trying to figure out whether the solution >>> needs to come from the compiler or the VM. (In the meantime, you can >>> make the Bar constructor but not class public, which should get you past >>> your current problem without opening additional security holes.) >> I think that, since this is a bug, there's no rush to get a fix in while >> we are figuring out what's the better way to fix it. If the outcome of >> the discussion is that we'll have to change the compiler, we'll do that >> when the time comes. It doesn't seem a super common issue anyway. > The root cause of this bug is the infamous 4071957 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957 > and to make a long story short, the EG of JSR 292 has decided to align > the semantics of method handles on the reflection API on that subject. For the records: a cheap way to fix this in the compiler would be to expand the bridging strategy we are currently using in some cases (i.e. super method reference calls) to cover these cases as well. Maurizio > >> Maurizio > R?mi > >>> On 12/18/2012 6:38 AM, Anna Kozlova wrote: >>>> Hello, >>>> >>>> >>>> >>>> Running the following class >>>> >>>> {code} >>>> >>>> public class FooBar { >>>> >>>> private static final class Bar { >>>> >>>> private Bar() { >>>> >>>> } >>>> >>>> } >>>> >>>> >>>> >>>> private interface I { >>>> >>>> Bar create(); >>>> >>>> } >>>> >>>> >>>> >>>> static void foo(I intf) {} >>>> >>>> >>>> >>>> public static void main(String[] args) throws Exception { >>>> >>>> foo(Bar::new); >>>> >>>> } >>>> >>>> } >>>> >>>> {code} >>>> >>>> >>>> >>>> fails with >>>> >>>> Exception in thread "main" java.lang.IncompatibleClassChangeError >>>> >>>> at >>>> java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa >>>> tives.java:383) >>>> >>>> at p.FooBar.main(FooBar.java:18) >>>> >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native >>>> Method) >>>> >>>> at >>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57 >>>> ) >>>> >>>> at >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl >>>> .java:43) >>>> >>>> at java.lang.reflect.Method.invoke(Method.java:474) >>>> >>>> at >>>> com.intellij.rt.execution.application.AppMain.main(AppMain.java:120) >>>> >>>> Caused by: java.lang.IllegalAccessException: member is private: >>>> p.FooBar$Bar.()void/invokeSpecial, from p.FooBar >>>> >>>> at >>>> java.lang.invoke.MemberName.makeAccessException(MemberName.java:732) >>>> >>>> at >>>> java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:1135) >>>> >>>> at >>>> java.lang.invoke.MethodHandles$Lookup.getDirectConstructor(MethodHandles.jav >>>> a:1243) >>>> >>>> at >>>> java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles >>>> .java:1270) >>>> >>>> at >>>> java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNa >>>> tives.java:381) >>>> >>>> ... 6 more >>>> >>>> >>>> >>>> If I convert method reference to lambda expression or anonymous class >>>> everything works correctly. Checked with b68. >>>> >>>> >>>> >>>> Thank you >>>> Anna >>>> >>>> >>>> >>>> > From venkats at agiledeveloper.com Tue Dec 18 13:40:25 2012 From: venkats at agiledeveloper.com (Venkat Subramaniam) Date: Tue, 18 Dec 2012 14:40:25 -0700 Subject: lambda expression parameters Message-ID: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> Hi Is there plans to make the inferred parameter of a lambda expression final by default. Right now, we can't specify the parameter is final unless we provide it with the type. In the spirit of leaning towards immutability, which is a better practice, would it be possible to (a) make all inferred parameters of lambda expressions final, and (b) to make it non-final, force the developers to explicitly request (like the mutable in F#). It's more of a wish-list, if that's something that can be considered. Thanks, Venkat From forax at univ-mlv.fr Tue Dec 18 14:17:40 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 18 Dec 2012 23:17:40 +0100 Subject: lambda expression parameters In-Reply-To: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> Message-ID: <50D0EB84.6080408@univ-mlv.fr> On 12/18/2012 10:40 PM, Venkat Subramaniam wrote: > Hi > > Is there plans to make the inferred parameter of a lambda expression final by default. > Right now, we can't specify the parameter is final unless we provide it with the type. > > In the spirit of leaning towards immutability, which is a better practice, would it be possible to > > (a) make all inferred parameters of lambda expressions final, and > (b) to make it non-final, force the developers to explicitly request (like the mutable in F#). > > It's more of a wish-list, if that's something that can be considered. Having local variable constant or not (exactly assigned once) is orthogonal to having object immutable or not. You can have an application with all local variables declared final with all objects (except Strings) that are mutable and vice versa. The only thing that is dangerous is if Java had allowed anonymous classes and now lambda to capture local variable (the address) instead of capturing its value. Before Java 8, declaring a local variable final or not was more a coding practice but in one case, when an anonymous class captures the value of a variable. In Java 8, you don't need to declare that local variable final any more, because the compiler is able to see if this variable is final or not, it's the effectively final rule. So there is no reason any more to declare local variable final but to enforce a coding style. > > Thanks, > > Venkat R?mi From brian.goetz at oracle.com Tue Dec 18 14:31:59 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 18 Dec 2012 17:31:59 -0500 Subject: lambda expression parameters In-Reply-To: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> Message-ID: <50D0EEDF.60500@oracle.com> Agreed that this is something that has the right "nudge" to it. One downside is that there is no keyword for "not final." Which means this is not a question about "final by default", but "final by decree", unless we're willing to introduce new syntax for mutable (which we're not.) That's not terrible -- most people would probably never even notice. So, reasonable suggestion. On 12/18/2012 4:40 PM, Venkat Subramaniam wrote: > Hi > > Is there plans to make the inferred parameter of a lambda expression final by default. > Right now, we can't specify the parameter is final unless we provide it with the type. > > In the spirit of leaning towards immutability, which is a better practice, would it be possible to > > (a) make all inferred parameters of lambda expressions final, and > (b) to make it non-final, force the developers to explicitly request (like the mutable in F#). > > It's more of a wish-list, if that's something that can be considered. > > Thanks, > > Venkat > From venkats at agiledeveloper.com Tue Dec 18 14:43:17 2012 From: venkats at agiledeveloper.com (Venkat Subramaniam) Date: Tue, 18 Dec 2012 15:43:17 -0700 Subject: lambda expression parameters In-Reply-To: <50D0EEDF.60500@oracle.com> References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> Message-ID: I'd love that "final by decree" :), would like it at least for the inferred parameters. Thanks Brian. Venkat On Dec 18, 2012, at 3:31 PM, Brian Goetz wrote: > Agreed that this is something that has the right "nudge" to it. > > One downside is that there is no keyword for "not final." Which means this is not a question about "final by default", but "final by decree", unless we're willing to introduce new syntax for mutable (which we're not.) That's not terrible -- most people would probably never even notice. So, reasonable suggestion. > > > > On 12/18/2012 4:40 PM, Venkat Subramaniam wrote: >> Hi >> >> Is there plans to make the inferred parameter of a lambda expression final by default. >> Right now, we can't specify the parameter is final unless we provide it with the type. >> >> In the spirit of leaning towards immutability, which is a better practice, would it be possible to >> >> (a) make all inferred parameters of lambda expressions final, and >> (b) to make it non-final, force the developers to explicitly request (like the mutable in F#). >> >> It's more of a wish-list, if that's something that can be considered. >> >> Thanks, >> >> Venkat >> From peter.levart at gmail.com Tue Dec 18 15:16:34 2012 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 19 Dec 2012 00:16:34 +0100 Subject: lambda expression parameters In-Reply-To: <50D0EEDF.60500@oracle.com> References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> Message-ID: <50D0F952.6060506@gmail.com> What about "sole" final, like: Predicate isUpper = (final s) -> s.toUppercase().equals(s); Regards, Peter On 12/18/2012 11:31 PM, Brian Goetz wrote: > Agreed that this is something that has the right "nudge" to it. > > One downside is that there is no keyword for "not final." Which means > this is not a question about "final by default", but "final by decree", > unless we're willing to introduce new syntax for mutable (which we're > not.) That's not terrible -- most people would probably never even > notice. So, reasonable suggestion. > > > > On 12/18/2012 4:40 PM, Venkat Subramaniam wrote: >> Hi >> >> Is there plans to make the inferred parameter of a lambda expression final by default. >> Right now, we can't specify the parameter is final unless we provide it with the type. >> >> In the spirit of leaning towards immutability, which is a better practice, would it be possible to >> >> (a) make all inferred parameters of lambda expressions final, and >> (b) to make it non-final, force the developers to explicitly request (like the mutable in F#). >> >> It's more of a wish-list, if that's something that can be considered. >> >> Thanks, >> >> Venkat >> From scolebourne at joda.org Tue Dec 18 15:50:52 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 18 Dec 2012 23:50:52 +0000 Subject: lambda expression parameters In-Reply-To: <50D0EEDF.60500@oracle.com> References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> Message-ID: I would support making all lambda parameters final. The syntax is distinct and different anyway, so this is a very natural thing to do. It also goes very well with the multi-threading/parallel messaging that the API is aiming for.In fact, my first response was surprise that this wasn't how they already worked. Stephen On 18 December 2012 22:31, Brian Goetz wrote: > Agreed that this is something that has the right "nudge" to it. > > One downside is that there is no keyword for "not final." Which means > this is not a question about "final by default", but "final by decree", > unless we're willing to introduce new syntax for mutable (which we're > not.) That's not terrible -- most people would probably never even > notice. So, reasonable suggestion. > > > > On 12/18/2012 4:40 PM, Venkat Subramaniam wrote: >> Hi >> >> Is there plans to make the inferred parameter of a lambda expression final by default. >> Right now, we can't specify the parameter is final unless we provide it with the type. >> >> In the spirit of leaning towards immutability, which is a better practice, would it be possible to >> >> (a) make all inferred parameters of lambda expressions final, and >> (b) to make it non-final, force the developers to explicitly request (like the mutable in F#). >> >> It's more of a wish-list, if that's something that can be considered. >> >> Thanks, >> >> Venkat >> > From misterm at gmail.com Tue Dec 18 15:55:32 2012 From: misterm at gmail.com (Michael Nascimento) Date: Tue, 18 Dec 2012 21:55:32 -0200 Subject: lambda expression parameters In-Reply-To: References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> Message-ID: I think they should be final when inferred. If types are formally declared, then they should not, to avoid confusion (too similar to regular parameter declaration) and to allow a way out if people really want to. Regards, Michael On Tue, Dec 18, 2012 at 9:50 PM, Stephen Colebourne wrote: > I would support making all lambda parameters final. The syntax is > distinct and different anyway, so this is a very natural thing to do. > It also goes very well with the multi-threading/parallel messaging > that the API is aiming for.In fact, my first response was surprise > that this wasn't how they already worked. > > Stephen > > > On 18 December 2012 22:31, Brian Goetz wrote: >> Agreed that this is something that has the right "nudge" to it. >> >> One downside is that there is no keyword for "not final." Which means >> this is not a question about "final by default", but "final by decree", >> unless we're willing to introduce new syntax for mutable (which we're >> not.) That's not terrible -- most people would probably never even >> notice. So, reasonable suggestion. >> >> >> >> On 12/18/2012 4:40 PM, Venkat Subramaniam wrote: >>> Hi >>> >>> Is there plans to make the inferred parameter of a lambda expression final by default. >>> Right now, we can't specify the parameter is final unless we provide it with the type. >>> >>> In the spirit of leaning towards immutability, which is a better practice, would it be possible to >>> >>> (a) make all inferred parameters of lambda expressions final, and >>> (b) to make it non-final, force the developers to explicitly request (like the mutable in F#). >>> >>> It's more of a wish-list, if that's something that can be considered. >>> >>> Thanks, >>> >>> Venkat >>> >> > From david.holmes at oracle.com Tue Dec 18 16:43:51 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Dec 2012 10:43:51 +1000 Subject: lambda expression parameters In-Reply-To: <50D0EEDF.60500@oracle.com> References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> Message-ID: <50D10DC7.2090408@oracle.com> I don't grok the problem. If the parameter is not modified then it is effectively final. Making parameters final is then only an error-detection mechanism, and I don't see that is warranted in lambda expressions. So I don't see "final by default" as warranted. Having to add back the inferred type to enable final to be added doesn't seem like a large burden. On the other hand can't the compiler accept parameter modifiers even if it infers the type? David On 19/12/2012 8:31 AM, Brian Goetz wrote: > Agreed that this is something that has the right "nudge" to it. > > One downside is that there is no keyword for "not final." Which means > this is not a question about "final by default", but "final by decree", > unless we're willing to introduce new syntax for mutable (which we're > not.) That's not terrible -- most people would probably never even > notice. So, reasonable suggestion. > > > > On 12/18/2012 4:40 PM, Venkat Subramaniam wrote: >> Hi >> >> Is there plans to make the inferred parameter of a lambda expression final by default. >> Right now, we can't specify the parameter is final unless we provide it with the type. >> >> In the spirit of leaning towards immutability, which is a better practice, would it be possible to >> >> (a) make all inferred parameters of lambda expressions final, and >> (b) to make it non-final, force the developers to explicitly request (like the mutable in F#). >> >> It's more of a wish-list, if that's something that can be considered. >> >> Thanks, >> >> Venkat >> > From venkats at agiledeveloper.com Tue Dec 18 16:57:05 2012 From: venkats at agiledeveloper.com (Venkat Subramaniam) Date: Tue, 18 Dec 2012 17:57:05 -0700 Subject: lambda expression parameters In-Reply-To: <50D10DC7.2090408@oracle.com> References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> <50D10DC7.2090408@oracle.com> Message-ID: <58BDADBA-1BDA-44D1-8906-7C0D4486E4BF@agiledeveloper.com> David, Right now (build b68) the compiler refuses final modifier for inferred types. The error detection mechanism is a reasonably good reason IMHO to have final as default (or decree). This may be a good opportunity, at the design time, to lean on the side of good practices, especially in supporting a feature that so much favors immutability. Thanks, Venkat On Dec 18, 2012, at 5:43 PM, David Holmes wrote: > I don't grok the problem. If the parameter is not modified then it is effectively final. Making parameters final is then only an error-detection mechanism, and I don't see that is warranted in lambda expressions. So I don't see "final by default" as warranted. > > Having to add back the inferred type to enable final to be added doesn't seem like a large burden. On the other hand can't the compiler accept parameter modifiers even if it infers the type? > > David > > On 19/12/2012 8:31 AM, Brian Goetz wrote: >> Agreed that this is something that has the right "nudge" to it. >> >> One downside is that there is no keyword for "not final." Which means >> this is not a question about "final by default", but "final by decree", >> unless we're willing to introduce new syntax for mutable (which we're >> not.) That's not terrible -- most people would probably never even >> notice. So, reasonable suggestion. >> >> >> >> On 12/18/2012 4:40 PM, Venkat Subramaniam wrote: >>> Hi >>> >>> Is there plans to make the inferred parameter of a lambda expression final by default. >>> Right now, we can't specify the parameter is final unless we provide it with the type. >>> >>> In the spirit of leaning towards immutability, which is a better practice, would it be possible to >>> >>> (a) make all inferred parameters of lambda expressions final, and >>> (b) to make it non-final, force the developers to explicitly request (like the mutable in F#). >>> >>> It's more of a wish-list, if that's something that can be considered. >>> >>> Thanks, >>> >>> Venkat >>> >> From julianhyde at gmail.com Tue Dec 18 16:57:23 2012 From: julianhyde at gmail.com (Julian Hyde) Date: Tue, 18 Dec 2012 16:57:23 -0800 Subject: lambda expression parameters In-Reply-To: <50D10DC7.2090408@oracle.com> References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> <50D10DC7.2090408@oracle.com> Message-ID: <8808CEA2-8C15-4AE2-9975-F3FF017127E9@gmail.com> My opinion is that lambda parameters should be final by decree. For example, in for (int i = 0; i < 10; i++) { foo(i -> ++i); } the parameter 'i' to the lambda doesn't have a traditional declaration (such as 'int i' or 'final int i') and so a naive reader would be surprised to learn that it is actually different from the variable 'i' in the enclosing loop. (Much the same issue as variables captured as members of anonymous inner classes.) The compiler should give an error, and the naive reader would become a little less naive. Julian From daniel.smith at oracle.com Tue Dec 18 18:15:40 2012 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 18 Dec 2012 19:15:40 -0700 Subject: lambda expression parameters In-Reply-To: <50D10DC7.2090408@oracle.com> References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> <50D10DC7.2090408@oracle.com> Message-ID: On Dec 18, 2012, at 5:43 PM, David Holmes wrote: > I don't grok the problem. If the parameter is not modified then it is > effectively final. Making parameters final is then only an > error-detection mechanism, and I don't see that is warranted in lambda > expressions. So I don't see "final by default" as warranted. > > Having to add back the inferred type to enable final to be added doesn't > seem like a large burden. Yeah, I think I agree with David. The times when it seems most useful to say "this parameter is final and I definitely don't want anyone changing it" are when you've got a large lambda body, and then it's really not so painful to give your parameters full declarations ('final String s'). It's worth noting that 'final' parameters and local variables didn't exist in the original language and were only added to support the "captured variables must be final" rule when anonymous/local classes were added. If "effectively final" were an option back then (don't know if it's something they thought about or not), I would bet we still wouldn't have 'final' parameters and local variables. They're really a lot less useful than 'final' fields -- because all interaction is in a single thread and within a single block of code. > On the other hand can't the compiler accept > parameter modifiers even if it infers the type? No, there are two syntax options: list of identifiers, or full method parameter list. Less complex that way. ?Dan From daniel.smith at oracle.com Tue Dec 18 18:23:48 2012 From: daniel.smith at oracle.com (Dan Smith) Date: Tue, 18 Dec 2012 19:23:48 -0700 Subject: lambda expression parameters In-Reply-To: <8808CEA2-8C15-4AE2-9975-F3FF017127E9@gmail.com> References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> <50D10DC7.2090408@oracle.com> <8808CEA2-8C15-4AE2-9975-F3FF017127E9@gmail.com> Message-ID: <5221ADA8-704F-471B-B893-7A251C91279D@oracle.com> On Dec 18, 2012, at 5:57 PM, Julian Hyde wrote: > My opinion is that lambda parameters should be final by decree. For example, in > > for (int i = 0; i < 10; i++) { > foo(i -> ++i); > } > > the parameter 'i' to the lambda doesn't have a traditional declaration (such as 'int i' or 'final int i') and so a naive reader would be surprised to learn that it is actually different from the variable 'i' in the enclosing loop. We've got this covered: lambda parameters are not allowed to shadowing local variables in the enclosing context. I thought about a similar example, without shadowing: list.map(x -> ++x) or list.map(x -> x = x+1) The user might not realize the the mutation is meaningless, but it's harmless: the effect of the 'map', in any case, is to increment all elements by one. More problematic if the naive user tries post-increment: list.map(x -> x++) Now the 'map' is a no-op. Not good, although this indicates a basic misunderstanding about what lambdas mean, and one that beginners will probably figure out pretty quickly. But maybe this is the best argument for _some_ sort of special error detection. ?Dan From brian.goetz at oracle.com Tue Dec 18 19:10:46 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 19 Dec 2012 03:10:46 +0000 Subject: hg: lambda/lambda/jdk: Add {Int,Long,Double}BiFunction. Message-ID: <20121219031118.CDF0B47257@hg.openjdk.java.net> Changeset: a6af10079310 Author: briangoetz Date: 2012-12-18 22:10 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a6af10079310 Add {Int,Long,Double}BiFunction. Contributed-by: dl + src/share/classes/java/util/function/DoubleBiFunction.java + src/share/classes/java/util/function/IntBiFunction.java + src/share/classes/java/util/function/LongBiFunction.java From brian.goetz at oracle.com Tue Dec 18 19:35:58 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 19 Dec 2012 03:35:58 +0000 Subject: hg: lambda/lambda/jdk: Modifications to Spliterator spec and API as recommended by Doug. Message-ID: <20121219033618.D1EBD4725F@hg.openjdk.java.net> Changeset: 01db914275e8 Author: briangoetz Date: 2012-12-18 22:35 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/01db914275e8 Modifications to Spliterator spec and API as recommended by Doug. ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/Spliterator.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/stream/op/NodeUtils.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/op/OpUtils.java ! src/share/classes/java/util/stream/op/SpinedBuffer.java ! src/share/classes/java/util/stream/primitive/IntCumulateOp.java ! src/share/classes/java/util/stream/primitive/IntNodeUtils.java ! src/share/classes/java/util/stream/primitive/IntSpinedBuffer.java ! src/share/classes/java/util/stream/primitive/PrimitiveNodes.java ! src/share/classes/java/util/stream/primitive/PrimitiveStreams.java ! test-ng/tests/org/openjdk/tests/java/util/stream/SpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SpinedBufferTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestData.java From brian.goetz at oracle.com Tue Dec 18 20:33:20 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 19 Dec 2012 04:33:20 +0000 Subject: hg: lambda/lambda/jdk: Misc cleanups Message-ID: <20121219043333.5ACBD47268@hg.openjdk.java.net> Changeset: ee6b63782036 Author: briangoetz Date: 2012-12-18 23:33 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ee6b63782036 Misc cleanups ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/PrimitiveStreams.java ! src/share/classes/java/util/stream/reduce/Reducers.java ! src/share/classes/java/util/stream/reduce/Tabulators.java ! test-ng/tests/org/openjdk/tests/java/util/stream/TabulatorsTest.java From brian.goetz at oracle.com Tue Dec 18 21:02:37 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 19 Dec 2012 05:02:37 +0000 Subject: hg: lambda/lambda/jdk: Rename and refactor flatMap -> mapMulti Message-ID: <20121219050251.8E95047269@hg.openjdk.java.net> Changeset: 39776de7f893 Author: briangoetz Date: 2012-12-19 00:02 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/39776de7f893 Rename and refactor flatMap -> mapMulti - src/share/classes/java/util/function/FlatMapper.java + src/share/classes/java/util/function/MultiFunction.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java - src/share/classes/java/util/stream/op/FlatMapOp.java + src/share/classes/java/util/stream/op/MultiMapOp.java ! src/share/classes/java/util/stream/primitive/IntFlatMapper.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlatMapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SpinedBufferTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java From paul.sandoz at oracle.com Wed Dec 19 00:39:18 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 19 Dec 2012 08:39:18 +0000 Subject: hg: lambda/lambda/jdk: Javadoc typos. Message-ID: <20121219083939.CBAD647278@hg.openjdk.java.net> Changeset: 8db59a175870 Author: psandoz Date: 2012-12-19 09:38 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8db59a175870 Javadoc typos. ! src/share/classes/java/util/stream/Spliterator.java From paul.sandoz at oracle.com Wed Dec 19 01:05:31 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 19 Dec 2012 09:05:31 +0000 Subject: hg: lambda/lambda/jdk: Rename and refactor flatMap -> mapMulti for IntStream. Message-ID: <20121219090544.58C5E47279@hg.openjdk.java.net> Changeset: c24c94e92f85 Author: psandoz Date: 2012-12-19 10:03 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c24c94e92f85 Rename and refactor flatMap -> mapMulti for IntStream. - src/share/classes/java/util/stream/primitive/IntFlatMapOp.java - src/share/classes/java/util/stream/primitive/IntFlatMapper.java + src/share/classes/java/util/stream/primitive/IntMultiFunction.java + src/share/classes/java/util/stream/primitive/IntMultiMapOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntStream.java - test-ng/tests/org/openjdk/tests/java/util/stream/op/FlatMapOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/MultiMapOpTest.java - test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntFlatMapOpTest.java + test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntMultiMapOpTest.java From paul.sandoz at oracle.com Wed Dec 19 01:52:51 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 19 Dec 2012 09:52:51 +0000 Subject: hg: lambda/lambda/jdk: Merge int fold and int seedless fold into one class. Message-ID: <20121219095321.D81FC4727A@hg.openjdk.java.net> Changeset: 21e3182cb946 Author: psandoz Date: 2012-12-19 10:52 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/21e3182cb946 Merge int fold and int seedless fold into one class. ! src/share/classes/java/util/stream/primitive/IntFoldOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java - src/share/classes/java/util/stream/primitive/IntSeedlessFoldOp.java ! src/share/classes/java/util/stream/primitive/IntStream.java From paul.sandoz at oracle.com Wed Dec 19 02:18:23 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 19 Dec 2012 10:18:23 +0000 Subject: hg: lambda/lambda/jdk: Primitive op specializations that have default methods for Message-ID: <20121219101929.1C07A4727C@hg.openjdk.java.net> Changeset: 334a58c9543b Author: psandoz Date: 2012-12-19 11:18 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/334a58c9543b Primitive op specializations that have default methods for input/output shape. ! src/share/classes/java/util/stream/op/ForEachOp.java ! src/share/classes/java/util/stream/primitive/IntAverageOp.java ! src/share/classes/java/util/stream/primitive/IntCollectorOps.java ! src/share/classes/java/util/stream/primitive/IntCumulateOp.java ! src/share/classes/java/util/stream/primitive/IntFilterOp.java ! src/share/classes/java/util/stream/primitive/IntFoldOp.java ! src/share/classes/java/util/stream/primitive/IntMapOp.java ! src/share/classes/java/util/stream/primitive/IntMultiMapOp.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java ! src/share/classes/java/util/stream/primitive/IntTeeOp.java ! src/share/classes/java/util/stream/primitive/IntToArrayOp.java + src/share/classes/java/util/stream/primitive/PrimitiveOps.java From dmitry.bessonov at oracle.com Wed Dec 19 03:10:24 2012 From: dmitry.bessonov at oracle.com (Dmitry Bessonov) Date: Wed, 19 Dec 2012 15:10:24 +0400 Subject: b69 regression: concat(parallel, infinite).sequential().iterator() -> OOM Message-ID: <50D1A0A0.6010200@oracle.com> Hello, A regression has been noticed in b69. The following code leads basically to OOM with b69. -------------- import java.util.Arrays; import java.util.Iterator; import java.util.stream.Stream; import java.util.stream.Streams; public class ConcatParallelAndInfinite { public static void main(String[] args) { Stream parallel = Arrays.asList("a", "b").parallelStream(); Stream infinite = Streams.repeat("x"); Iterator iterator = Streams.concat(parallel, infinite).sequential().iterator(); System.out.println("iterator = " + iterator); } } -------------- the output will be something like: Exception in thread "ForkJoinPool.commonPool-worker-7" Exception in thread "ForkJoinPool.commonPool-worker-7" Exception in thread "ForkJoinPool.commonPool-worker-1" Exception in thread "ForkJoinPool.commonPool-worker-11" Exception in thread "ForkJoinPool.commonPool-worker-1" Exception in thread "ForkJoinPool.commonPool-worker-9" Exception in thread "ForkJoinPool.commonPool-worker-15" java.lang.OutOfMemoryError: Java heap space java.lang.OutOfMemoryError: Java heap space Exception in thread "ForkJoinPool.commonPool-worker-13" java.lang.OutOfMemoryError: Java heap space Exception in thread "ForkJoinPool.commonPool-worker-11" Exception in thread "ForkJoinPool.commonPool-worker-5" With b68 code above works just fine (assuming .parallelStream() renamed back to .parallel()) printing out the iterator instance. -Dmitry -------------- next part -------------- import java.util.Arrays; import java.util.Iterator; import java.util.stream.Stream; import java.util.stream.Streams; public class ConcatParallelAndInfinite { public static void main(String[] args) { Stream parallel = Arrays.asList("a", "b").parallelStream(); Stream infinite = Streams.repeat("x"); Iterator iterator = Streams.concat(parallel, infinite).sequential().iterator(); System.out.println("iterator = " + iterator); } } From paul.sandoz at oracle.com Wed Dec 19 03:53:29 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 19 Dec 2012 12:53:29 +0100 Subject: b69 regression: concat(parallel, infinite).sequential().iterator() -> OOM In-Reply-To: <50D1A0A0.6010200@oracle.com> References: <50D1A0A0.6010200@oracle.com> Message-ID: <210D9124-9347-4BBC-A88A-549B18B4FDAE@oracle.com> Hi, I suspect previously that the concat operation resulted in a sequential stream, or one that delayed doing anything until Iterator.hasNext/next was called. Now, since one of the streams is a parallel stream the concatenated stream is taken to be a parallel stream too. The idea being we try to squeeze as much parallelism as we possibly can. sequential() is a barrier when the upstream is parallel, so it is always gonna barf when given infinite input (as will be the case for any non-short-circuiting terminal operation). Try: Streams.concat(parallel, infinite).limit(10).sequential().iterator(); Paul. On Dec 19, 2012, at 12:10 PM, Dmitry Bessonov wrote: > Hello, > > A regression has been noticed in b69. > The following code leads basically to OOM with b69. > > -------------- > import java.util.Arrays; > import java.util.Iterator; > import java.util.stream.Stream; > import java.util.stream.Streams; > > public class ConcatParallelAndInfinite { > > public static void main(String[] args) { > Stream parallel = Arrays.asList("a", "b").parallelStream(); > Stream infinite = Streams.repeat("x"); > Iterator iterator = Streams.concat(parallel, infinite).sequential().iterator(); > System.out.println("iterator = " + iterator); > } > } > -------------- > > the output will be something like: > > Exception in thread "ForkJoinPool.commonPool-worker-7" Exception in thread "ForkJoinPool.commonPool-worker-7" Exception in thread "ForkJoinPool.commonPool-worker-1" Exception in thread "ForkJoinPool.commonPool-worker-11" Exception in thread "ForkJoinPool.commonPool-worker-1" Exception in thread "ForkJoinPool.commonPool-worker-9" Exception in thread "ForkJoinPool.commonPool-worker-15" java.lang.OutOfMemoryError: Java heap space > java.lang.OutOfMemoryError: Java heap space > Exception in thread "ForkJoinPool.commonPool-worker-13" java.lang.OutOfMemoryError: Java heap space > Exception in thread "ForkJoinPool.commonPool-worker-11" Exception in thread "ForkJoinPool.commonPool-worker-5" > > > With b68 code above works just fine > (assuming .parallelStream() renamed back to .parallel()) > printing out the iterator instance. > > > -Dmitry > From scolebourne at joda.org Wed Dec 19 05:26:00 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 19 Dec 2012 13:26:00 +0000 Subject: Method reference toString Message-ID: Has a decision been taken on the toString() of a method reference? And I guess of lambdas more generally? In JSR-310 I'm starting to use method references as the key for parsing (instead of a class reference), but I'd like to be able to use the toString() to produce nice error messages as well. Stephen From brian.goetz at oracle.com Wed Dec 19 06:21:19 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 19 Dec 2012 09:21:19 -0500 Subject: Method reference toString In-Reply-To: References: Message-ID: <50D1CD5F.6070100@oracle.com> No, the EG has not decided on that to date. What do you mean by key? Remember that you can can't count on identity for lambdas/method refs, making them unsuitable as keys in Maps... On 12/19/2012 8:26 AM, Stephen Colebourne wrote: > Has a decision been taken on the toString() of a method reference? And > I guess of lambdas more generally? > > In JSR-310 I'm starting to use method references as the key for > parsing (instead of a class reference), but I'd like to be able to use > the toString() to produce nice error messages as well. > > Stephen > From scolebourne at joda.org Wed Dec 19 06:34:31 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 19 Dec 2012 14:34:31 +0000 Subject: Method reference toString In-Reply-To: <50D1CD5F.6070100@oracle.com> References: <50D1CD5F.6070100@oracle.com> Message-ID: By "key" I mean this. Previously, I used: LocalDate date = parser.parse(LocalDate.class) now I use LocalDate date = parser.parse(LocalDate::from) I was hoping to have an error message referencing "LocalDate::from", the toString form of the method ref. By no identity, is the following guaranteed to be true? public static Query QUERY = LocalDate::from; assert QUERY == QUERY (I assume so...) Stephen On 19 December 2012 14:21, Brian Goetz wrote: > No, the EG has not decided on that to date. > > What do you mean by key? Remember that you can can't count on identity for > lambdas/method refs, making them unsuitable as keys in Maps... > > > On 12/19/2012 8:26 AM, Stephen Colebourne wrote: >> >> Has a decision been taken on the toString() of a method reference? And >> I guess of lambdas more generally? >> >> In JSR-310 I'm starting to use method references as the key for >> parsing (instead of a class reference), but I'd like to be able to use >> the toString() to produce nice error messages as well. >> >> Stephen >> > From brian.goetz at oracle.com Wed Dec 19 06:48:18 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 19 Dec 2012 09:48:18 -0500 Subject: Method reference toString In-Reply-To: References: <50D1CD5F.6070100@oracle.com> Message-ID: <50D1D3B2.2000003@oracle.com> > By no identity, is the following guaranteed to be true? > > public static Query QUERY = LocalDate::from; > assert QUERY == QUERY Yes. But not: assert QUERY == LocalDate::from From zhong.j.yu at gmail.com Wed Dec 19 07:44:53 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Wed, 19 Dec 2012 09:44:53 -0600 Subject: lambda expression parameters In-Reply-To: References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> <50D10DC7.2090408@oracle.com> Message-ID: On Tue, Dec 18, 2012 at 8:15 PM, Dan Smith wrote: > On Dec 18, 2012, at 5:43 PM, David Holmes wrote: > >> I don't grok the problem. If the parameter is not modified then it is >> effectively final. Making parameters final is then only an >> error-detection mechanism, and I don't see that is warranted in lambda >> expressions. So I don't see "final by default" as warranted. >> >> Having to add back the inferred type to enable final to be added doesn't >> seem like a large burden. > > Yeah, I think I agree with David. The times when it seems most useful to say "this parameter is final and I definitely don't want anyone changing it" are when you've got a large lambda body, and then it's really not so painful to give your parameters full declarations ('final String s'). > > It's worth noting that 'final' parameters and local variables didn't exist in the original language and were only added to support the "captured variables must be final" rule when anonymous/local classes were added. If "effectively final" were an option back then (don't know if it's something they thought about or not), I would bet we still wouldn't have 'final' parameters and local variables. They're really a lot less useful than 'final' fields -- because all interaction is in a single thread and within a single block of code. Agreed, although most method parameters and many local variables are conceptually final, people don't bother to mark them final. Making method parameters implicitly final is inconsistent with existing practices; the benefit is dubious: If a programmer assigns a new value to a method parameter, and later reads it, it is very likely intentional, there's no need for alarm here. If a programmer assigns a new value to a method parameter, and never reads it, it is probably a mistake; fortunately IDEs will raise a warning for it. Zhong Yu > >> On the other hand can't the compiler accept >> parameter modifiers even if it infers the type? > > No, there are two syntax options: list of identifiers, or full method parameter list. Less complex that way. > > ?Dan > From ricky.clarkson at gmail.com Wed Dec 19 08:04:44 2012 From: ricky.clarkson at gmail.com (Ricky Clarkson) Date: Wed, 19 Dec 2012 13:04:44 -0300 Subject: lambda expression parameters In-Reply-To: References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> <50D10DC7.2090408@oracle.com> Message-ID: I'd just like to raise one potential case for making it implicitly final: Iterable list = someNumbers.map(x -> x = 5); (If it really returns a Stream, Streamable, CanBeStreamed or NotTonightDearImBusyStreaming, please give me some leeway.) The programmer is left wondering why the compiler says that map returns an Iterable instead of an Iterable, and it's all because he used = instead of ==. The programmer then wonders why Java didn't just give him a compile error when he assigned to the parameter, after all assigning to the parameter there is basically a no-op. On Wed, Dec 19, 2012 at 1:44 PM, Zhong Yu wrote: > On Tue, Dec 18, 2012 at 8:15 PM, Dan Smith > wrote: > > On Dec 18, 2012, at 5:43 PM, David Holmes > wrote: > > > >> I don't grok the problem. If the parameter is not modified then it is > >> effectively final. Making parameters final is then only an > >> error-detection mechanism, and I don't see that is warranted in lambda > >> expressions. So I don't see "final by default" as warranted. > >> > >> Having to add back the inferred type to enable final to be added doesn't > >> seem like a large burden. > > > > Yeah, I think I agree with David. The times when it seems most useful > to say "this parameter is final and I definitely don't want anyone changing > it" are when you've got a large lambda body, and then it's really not so > painful to give your parameters full declarations ('final String s'). > > > > It's worth noting that 'final' parameters and local variables didn't > exist in the original language and were only added to support the "captured > variables must be final" rule when anonymous/local classes were added. If > "effectively final" were an option back then (don't know if it's something > they thought about or not), I would bet we still wouldn't have 'final' > parameters and local variables. They're really a lot less useful than > 'final' fields -- because all interaction is in a single thread and within > a single block of code. > > Agreed, although most method parameters and many local variables are > conceptually final, people don't bother to mark them final. > > Making method parameters implicitly final is inconsistent with > existing practices; the benefit is dubious: > > If a programmer assigns a new value to a method parameter, and later > reads it, it is very likely intentional, there's no need for alarm > here. > > If a programmer assigns a new value to a method parameter, and never > reads it, it is probably a mistake; fortunately IDEs will raise a > warning for it. > > Zhong Yu > > > > >> On the other hand can't the compiler accept > >> parameter modifiers even if it infers the type? > > > > No, there are two syntax options: list of identifiers, or full method > parameter list. Less complex that way. > > > > ?Dan > > > > From venkats at agiledeveloper.com Wed Dec 19 08:13:39 2012 From: venkats at agiledeveloper.com (Venkat Subramaniam) Date: Wed, 19 Dec 2012 09:13:39 -0700 Subject: lambda expression parameters In-Reply-To: References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> <50D10DC7.2090408@oracle.com> Message-ID: Over the past couple of years I have been caught at least twice by bugs where I wasted significant time. In both cases, the programmer had modified the parameter of the method and in the process introduced the bugs. I have since started marking my method parameters final (call me paranoid). I find it really odd that anyone would want to modify the parameters, but I have seen it happen. One thing I really appreciate in languages that support functional style (hybrid or not) is the treatment of parameters as final by default. I fully understand this can't be done for Java for regular methods. I sincerely thing this is a good opportunity for such treatment for parameters to lambda expressions. I hope this is given a good consideration among the key decision makers. Thank you. Venkat On Dec 19, 2012, at 9:04 AM, Ricky Clarkson wrote: > I'd just like to raise one potential case for making it implicitly final: > > Iterable list = someNumbers.map(x -> x = 5); > > (If it really returns a Stream, Streamable, CanBeStreamed or > NotTonightDearImBusyStreaming, please give me some leeway.) > > The programmer is left wondering why the compiler says that map returns an > Iterable instead of an Iterable, and it's all because he > used = instead of ==. The programmer then wonders why Java didn't just > give him a compile error when he assigned to the parameter, after all > assigning to the parameter there is basically a no-op. > > > On Wed, Dec 19, 2012 at 1:44 PM, Zhong Yu wrote: > >> On Tue, Dec 18, 2012 at 8:15 PM, Dan Smith >> wrote: >>> On Dec 18, 2012, at 5:43 PM, David Holmes >> wrote: >>> >>>> I don't grok the problem. If the parameter is not modified then it is >>>> effectively final. Making parameters final is then only an >>>> error-detection mechanism, and I don't see that is warranted in lambda >>>> expressions. So I don't see "final by default" as warranted. >>>> >>>> Having to add back the inferred type to enable final to be added doesn't >>>> seem like a large burden. >>> >>> Yeah, I think I agree with David. The times when it seems most useful >> to say "this parameter is final and I definitely don't want anyone changing >> it" are when you've got a large lambda body, and then it's really not so >> painful to give your parameters full declarations ('final String s'). >>> >>> It's worth noting that 'final' parameters and local variables didn't >> exist in the original language and were only added to support the "captured >> variables must be final" rule when anonymous/local classes were added. If >> "effectively final" were an option back then (don't know if it's something >> they thought about or not), I would bet we still wouldn't have 'final' >> parameters and local variables. They're really a lot less useful than >> 'final' fields -- because all interaction is in a single thread and within >> a single block of code. >> >> Agreed, although most method parameters and many local variables are >> conceptually final, people don't bother to mark them final. >> >> Making method parameters implicitly final is inconsistent with >> existing practices; the benefit is dubious: >> >> If a programmer assigns a new value to a method parameter, and later >> reads it, it is very likely intentional, there's no need for alarm >> here. >> >> If a programmer assigns a new value to a method parameter, and never >> reads it, it is probably a mistake; fortunately IDEs will raise a >> warning for it. >> >> Zhong Yu >> >>> >>>> On the other hand can't the compiler accept >>>> parameter modifiers even if it infers the type? >>> >>> No, there are two syntax options: list of identifiers, or full method >> parameter list. Less complex that way. >>> >>> ?Dan >>> >> >> > From forax at univ-mlv.fr Wed Dec 19 08:32:26 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 19 Dec 2012 17:32:26 +0100 Subject: lambda expression parameters In-Reply-To: References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> <50D10DC7.2090408@oracle.com> Message-ID: <50D1EC1A.1050404@univ-mlv.fr> On 12/19/2012 05:13 PM, Venkat Subramaniam wrote: > Over the past couple of years I have been caught at least twice by bugs where I wasted significant time. > In both cases, the programmer had modified the parameter of the method and in the process > introduced the bugs. I have since started marking my method parameters final (call me paranoid). > I find it really odd that anyone would want to modify the parameters, but I have seen it happen. > One thing I really appreciate in languages that support functional style (hybrid or not) is the treatment > of parameters as final by default. I fully understand this can't be done for Java for regular methods. > I sincerely thing this is a good opportunity for such treatment for parameters to lambda expressions. > I hope this is given a good consideration among the key decision makers. Thank you. The best way to enforce a coding style is to install a pre-commit hook on your VCS and do all the static analysis you want. also, I propose that all if, for and while in a lambda requires curly braces because my students with a Python background think that indenting the code is enough. > > Venkat R?mi > > On Dec 19, 2012, at 9:04 AM, Ricky Clarkson wrote: > >> I'd just like to raise one potential case for making it implicitly final: >> >> Iterable list = someNumbers.map(x -> x = 5); >> >> (If it really returns a Stream, Streamable, CanBeStreamed or >> NotTonightDearImBusyStreaming, please give me some leeway.) >> >> The programmer is left wondering why the compiler says that map returns an >> Iterable instead of an Iterable, and it's all because he >> used = instead of ==. The programmer then wonders why Java didn't just >> give him a compile error when he assigned to the parameter, after all >> assigning to the parameter there is basically a no-op. >> >> >> On Wed, Dec 19, 2012 at 1:44 PM, Zhong Yu wrote: >> >>> On Tue, Dec 18, 2012 at 8:15 PM, Dan Smith >>> wrote: >>>> On Dec 18, 2012, at 5:43 PM, David Holmes >>> wrote: >>>>> I don't grok the problem. If the parameter is not modified then it is >>>>> effectively final. Making parameters final is then only an >>>>> error-detection mechanism, and I don't see that is warranted in lambda >>>>> expressions. So I don't see "final by default" as warranted. >>>>> >>>>> Having to add back the inferred type to enable final to be added doesn't >>>>> seem like a large burden. >>>> Yeah, I think I agree with David. The times when it seems most useful >>> to say "this parameter is final and I definitely don't want anyone changing >>> it" are when you've got a large lambda body, and then it's really not so >>> painful to give your parameters full declarations ('final String s'). >>>> It's worth noting that 'final' parameters and local variables didn't >>> exist in the original language and were only added to support the "captured >>> variables must be final" rule when anonymous/local classes were added. If >>> "effectively final" were an option back then (don't know if it's something >>> they thought about or not), I would bet we still wouldn't have 'final' >>> parameters and local variables. They're really a lot less useful than >>> 'final' fields -- because all interaction is in a single thread and within >>> a single block of code. >>> >>> Agreed, although most method parameters and many local variables are >>> conceptually final, people don't bother to mark them final. >>> >>> Making method parameters implicitly final is inconsistent with >>> existing practices; the benefit is dubious: >>> >>> If a programmer assigns a new value to a method parameter, and later >>> reads it, it is very likely intentional, there's no need for alarm >>> here. >>> >>> If a programmer assigns a new value to a method parameter, and never >>> reads it, it is probably a mistake; fortunately IDEs will raise a >>> warning for it. >>> >>> Zhong Yu >>> >>>>> On the other hand can't the compiler accept >>>>> parameter modifiers even if it infers the type? >>>> No, there are two syntax options: list of identifiers, or full method >>> parameter list. Less complex that way. >>>> ?Dan >>>> >>> > From brian.goetz at oracle.com Wed Dec 19 08:55:23 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 19 Dec 2012 16:55:23 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121219165613.C37DC4728E@hg.openjdk.java.net> Changeset: 68f1d0672940 Author: briangoetz Date: 2012-12-19 11:47 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/68f1d0672940 Rename some SAM methods in accordance with EG discussions; remove primtive-specialization extends base-SAM; rationalize extends with XxxOperator SAMs ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/Map.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java ! src/share/classes/java/util/function/BiBlock.java ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Block.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/DoublePredicate.java ! src/share/classes/java/util/function/DoubleSupplier.java ! src/share/classes/java/util/function/DoubleUnaryOperator.java ! src/share/classes/java/util/function/IntBinaryOperator.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/IntPredicate.java ! src/share/classes/java/util/function/IntSupplier.java ! src/share/classes/java/util/function/IntUnaryOperator.java ! src/share/classes/java/util/function/LongBinaryOperator.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/LongFunction.java ! src/share/classes/java/util/function/LongPredicate.java ! src/share/classes/java/util/function/LongSupplier.java ! src/share/classes/java/util/function/LongUnaryOperator.java ! src/share/classes/java/util/function/UnaryOperator.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/stream/op/CumulateOp.java ! src/share/classes/java/util/stream/op/FoldOp.java ! src/share/classes/java/util/stream/op/MatchOp.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/op/SpinedBuffer.java ! src/share/classes/java/util/stream/primitive/IntCumulateOp.java ! src/share/classes/java/util/stream/primitive/IntFilterOp.java ! src/share/classes/java/util/stream/primitive/IntFoldOp.java ! src/share/classes/java/util/stream/primitive/IntMapOp.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntSeedlessFoldOp.java ! src/share/classes/java/util/stream/primitive/IntSpinedBuffer.java ! src/share/classes/java/util/stream/primitive/PrimitiveStreams.java ! src/share/classes/java/util/stream/primitive/RefToIntMapOp.java ! src/share/classes/java/util/stream/reduce/ConcurrentTabulators.java ! src/share/classes/java/util/stream/reduce/Reducers.java ! src/share/classes/java/util/stream/reduce/Tabulators.java ! test-ng/tests/org/openjdk/tests/java/lang/PrimitiveSumMinMaxTest.java ! test-ng/tests/org/openjdk/tests/java/util/function/DoubleUnaryOperatorTest.java ! test-ng/tests/org/openjdk/tests/java/util/function/IntUnaryOperatorTest.java ! test-ng/tests/org/openjdk/tests/java/util/function/LongUnaryOperatorTest.java ! test-ng/tests/org/openjdk/tests/java/util/function/UnaryOperatorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SequentialOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SpinedBufferTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestData.java ! test/java/util/function/PredicateTest.java Changeset: 791361965318 Author: briangoetz Date: 2012-12-19 11:55 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/791361965318 Merge ! src/share/classes/java/util/stream/primitive/IntCumulateOp.java ! src/share/classes/java/util/stream/primitive/IntFilterOp.java ! src/share/classes/java/util/stream/primitive/IntFoldOp.java ! src/share/classes/java/util/stream/primitive/IntMapOp.java From zhong.j.yu at gmail.com Wed Dec 19 09:17:09 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Wed, 19 Dec 2012 11:17:09 -0600 Subject: lambda expression parameters In-Reply-To: References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> <50D10DC7.2090408@oracle.com> Message-ID: On Wed, Dec 19, 2012 at 10:04 AM, Ricky Clarkson wrote: > I'd just like to raise one potential case for making it implicitly final: > > Iterable list = someNumbers.map(x -> x = 5); > > (If it really returns a Stream, Streamable, CanBeStreamed or > NotTonightDearImBusyStreaming, please give me some leeway.) > > The programmer is left wondering why the compiler says that map returns an > Iterable instead of an Iterable, and it's all because he > used = instead of ==. The programmer then wonders why Java didn't just give > him a compile error when he assigned to the parameter, after all assigning > to the parameter there is basically a no-op. Static analyzers can catch that. For example in IntelliJ int f(int x) { return x++; } will raise a noticeable warning: "The value changed at x++ is never used" int f(int x) { return x=5; } will raise a less noticeable warning: "the value 5 assigned to x is never used" I haven't tried lambda in IntelliJ 12, but hopefully the same analysis exists; maybe it should be stronger and louder for lambda expressions. Javac probably doesn't need to perform such analysis by default. Zhong Yu > > On Wed, Dec 19, 2012 at 1:44 PM, Zhong Yu wrote: >> >> On Tue, Dec 18, 2012 at 8:15 PM, Dan Smith >> wrote: >> > On Dec 18, 2012, at 5:43 PM, David Holmes >> > wrote: >> > >> >> I don't grok the problem. If the parameter is not modified then it is >> >> effectively final. Making parameters final is then only an >> >> error-detection mechanism, and I don't see that is warranted in lambda >> >> expressions. So I don't see "final by default" as warranted. >> >> >> >> Having to add back the inferred type to enable final to be added >> >> doesn't >> >> seem like a large burden. >> > >> > Yeah, I think I agree with David. The times when it seems most useful >> > to say "this parameter is final and I definitely don't want anyone changing >> > it" are when you've got a large lambda body, and then it's really not so >> > painful to give your parameters full declarations ('final String s'). >> > >> > It's worth noting that 'final' parameters and local variables didn't >> > exist in the original language and were only added to support the "captured >> > variables must be final" rule when anonymous/local classes were added. If >> > "effectively final" were an option back then (don't know if it's something >> > they thought about or not), I would bet we still wouldn't have 'final' >> > parameters and local variables. They're really a lot less useful than >> > 'final' fields -- because all interaction is in a single thread and within a >> > single block of code. >> >> Agreed, although most method parameters and many local variables are >> conceptually final, people don't bother to mark them final. >> >> Making method parameters implicitly final is inconsistent with >> existing practices; the benefit is dubious: >> >> If a programmer assigns a new value to a method parameter, and later >> reads it, it is very likely intentional, there's no need for alarm >> here. >> >> If a programmer assigns a new value to a method parameter, and never >> reads it, it is probably a mistake; fortunately IDEs will raise a >> warning for it. >> >> Zhong Yu >> >> > >> >> On the other hand can't the compiler accept >> >> parameter modifiers even if it infers the type? >> > >> > No, there are two syntax options: list of identifiers, or full method >> > parameter list. Less complex that way. >> > >> > ?Dan >> > >> > From paul.sandoz at oracle.com Wed Dec 19 09:19:47 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 19 Dec 2012 17:19:47 +0000 Subject: hg: lambda/lambda/jdk: - allow flags on terminal ops. Message-ID: <20121219171959.4B74647290@hg.openjdk.java.net> Changeset: 7b61b86606e2 Author: psandoz Date: 2012-12-19 18:18 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7b61b86606e2 - allow flags on terminal ops. - propagate terminal ops through the distinct pipeline stages. (No action performed yet, but the plan is to back propagate NOT_ORDERED.) - re-introduce optimization if pipeline depth is zero and supplier of spliterator is backed by a Node. - ensure {Int}Stream.parallel() is lazy and does not unpack the spliterator from the source supplier or from the wrapping spliterator until evaluation occurs. ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/PipelineHelper.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/stream/op/FindOp.java ! src/share/classes/java/util/stream/op/IntermediateOp.java ! src/share/classes/java/util/stream/op/MatchOp.java ! src/share/classes/java/util/stream/op/StreamOp.java ! src/share/classes/java/util/stream/op/TerminalOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntToArrayOp.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java From maurizio.cimadamore at oracle.com Wed Dec 19 10:34:24 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 19 Dec 2012 18:34:24 +0000 Subject: hg: lambda/lambda/langtools: Fix: uncatched sam conversion failure exception lead to javac crash Message-ID: <20121219183430.1B9DF47293@hg.openjdk.java.net> Changeset: 3abe676095c6 Author: mcimadamore Date: 2012-12-19 18:33 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3abe676095c6 Fix: uncatched sam conversion failure exception lead to javac crash ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java + test/tools/javac/lambda/TargetType52.java + test/tools/javac/lambda/TargetType52.out From howard.lovatt at gmail.com Wed Dec 19 13:43:20 2012 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Thu, 20 Dec 2012 08:43:20 +1100 Subject: lambda expression parameters In-Reply-To: References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> <50D10DC7.2090408@oracle.com> Message-ID: <9582DAB1-6D81-4422-A404-6ADD7380D2BA@gmail.com> First a disclosure. I personally always declare everything final by default, it suits my 'immutable' programming style. The problem I have is that currently I can't declare final and infer type, therefore I get stuck with mutable arguments and the following problems: 1. The issue I have with saying that FindBugs, IDE, etc. will find if I assign and don't use, is that if I assign and use it won't. For my programming style a multiple assign is almost certainly a bug and this bug won't be found. 2. If you are assigning to something you probably want to be careful about type. Therefore it makes sense for inference to play safe and make it final and require you to explicitly declare type if mutable. Therefore I would rather have arguments final by default and force you to specify if you want mutable. -- Howard. Sent from my iPad On 20/12/2012, at 4:17 AM, Zhong Yu wrote: > On Wed, Dec 19, 2012 at 10:04 AM, Ricky Clarkson > wrote: >> I'd just like to raise one potential case for making it implicitly final: >> >> Iterable list = someNumbers.map(x -> x = 5); >> >> (If it really returns a Stream, Streamable, CanBeStreamed or >> NotTonightDearImBusyStreaming, please give me some leeway.) >> >> The programmer is left wondering why the compiler says that map returns an >> Iterable instead of an Iterable, and it's all because he >> used = instead of ==. The programmer then wonders why Java didn't just give >> him a compile error when he assigned to the parameter, after all assigning >> to the parameter there is basically a no-op. > > Static analyzers can catch that. For example in IntelliJ > > int f(int x) { return x++; } > > will raise a noticeable warning: "The value changed at x++ is never used" > > int f(int x) { return x=5; } > > will raise a less noticeable warning: "the value 5 assigned to x is never used" > > I haven't tried lambda in IntelliJ 12, but hopefully the same analysis > exists; maybe it should be stronger and louder for lambda expressions. > > Javac probably doesn't need to perform such analysis by default. > > Zhong Yu > > >> >> On Wed, Dec 19, 2012 at 1:44 PM, Zhong Yu wrote: >>> >>> On Tue, Dec 18, 2012 at 8:15 PM, Dan Smith >>> wrote: >>>> On Dec 18, 2012, at 5:43 PM, David Holmes >>>> wrote: >>>> >>>>> I don't grok the problem. If the parameter is not modified then it is >>>>> effectively final. Making parameters final is then only an >>>>> error-detection mechanism, and I don't see that is warranted in lambda >>>>> expressions. So I don't see "final by default" as warranted. >>>>> >>>>> Having to add back the inferred type to enable final to be added >>>>> doesn't >>>>> seem like a large burden. >>>> >>>> Yeah, I think I agree with David. The times when it seems most useful >>>> to say "this parameter is final and I definitely don't want anyone changing >>>> it" are when you've got a large lambda body, and then it's really not so >>>> painful to give your parameters full declarations ('final String s'). >>>> >>>> It's worth noting that 'final' parameters and local variables didn't >>>> exist in the original language and were only added to support the "captured >>>> variables must be final" rule when anonymous/local classes were added. If >>>> "effectively final" were an option back then (don't know if it's something >>>> they thought about or not), I would bet we still wouldn't have 'final' >>>> parameters and local variables. They're really a lot less useful than >>>> 'final' fields -- because all interaction is in a single thread and within a >>>> single block of code. >>> >>> Agreed, although most method parameters and many local variables are >>> conceptually final, people don't bother to mark them final. >>> >>> Making method parameters implicitly final is inconsistent with >>> existing practices; the benefit is dubious: >>> >>> If a programmer assigns a new value to a method parameter, and later >>> reads it, it is very likely intentional, there's no need for alarm >>> here. >>> >>> If a programmer assigns a new value to a method parameter, and never >>> reads it, it is probably a mistake; fortunately IDEs will raise a >>> warning for it. >>> >>> Zhong Yu >>> >>>> >>>>> On the other hand can't the compiler accept >>>>> parameter modifiers even if it infers the type? >>>> >>>> No, there are two syntax options: list of identifiers, or full method >>>> parameter list. Less complex that way. >>>> >>>> ?Dan > From talden at gmail.com Wed Dec 19 14:11:05 2012 From: talden at gmail.com (Talden) Date: Thu, 20 Dec 2012 11:11:05 +1300 Subject: lambda expression parameters In-Reply-To: <9582DAB1-6D81-4422-A404-6ADD7380D2BA@gmail.com> References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> <50D10DC7.2090408@oracle.com> <9582DAB1-6D81-4422-A404-6ADD7380D2BA@gmail.com> Message-ID: On Thu, Dec 20, 2012 at 10:43 AM, Howard Lovatt wrote: > First a disclosure. I personally always declare everything final by > default, it suits my 'immutable' programming style. > That is the team guidance here as well. Omitting final is an indicator you intend to treat it as a variable. If Java were done over from scratch it would be tempting to flip it on it's head an make everything implicitly final unless marked as a 'var'. Heck it'd be tempting to treat classes as implicitly final to promote composition over inheritance too - though 'var' would be an odd choice of word there and interfaces would probably want to continue to be extendable making it inconsistent (not good for implicit rules). It would be a shame to not be able to declare final without retaining the implicit typing. R?mi suggested that the best solution is a VCS pre-commit hook which is a good solution but not my preference. Creating a blocker for commit that could significantly delay the timeliness of the commit seems less productive than just doing static analysis performed as part of a CI build plan. Builds on release-branches can be more stringent and consider more of the warnings as errors to catch any aberrations that weren't caught in review, on subsequent fix commits or marked as intentional. Providing the ability to get the list of warnings as part of locally building it is a good idea so that developers can self-audit just as they should for some if not all of the unit-testing suite too (which again should be a standard part of the CI build plan). -- Aaron Scott-Boddendijk From zhong.j.yu at gmail.com Wed Dec 19 15:38:57 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Wed, 19 Dec 2012 17:38:57 -0600 Subject: lambda expression parameters In-Reply-To: <9582DAB1-6D81-4422-A404-6ADD7380D2BA@gmail.com> References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> <50D10DC7.2090408@oracle.com> <9582DAB1-6D81-4422-A404-6ADD7380D2BA@gmail.com> Message-ID: On Wed, Dec 19, 2012 at 3:43 PM, Howard Lovatt wrote: > First a disclosure. I personally always declare everything final by default, it suits my 'immutable' programming style. > > The problem I have is that currently I can't declare final and infer type, therefore I get stuck with mutable arguments and the following problems: > > 1. The issue I have with saying that FindBugs, IDE, etc. will find if I assign and don't use, is that if I assign and use it won't. For my programming style a multiple assign is almost certainly a bug and this bug won't be found. > > 2. If you are assigning to something you probably want to be careful about type. Therefore it makes sense for inference to play safe and make it final and require you to explicitly declare type if mutable. > > Therefore I would rather have arguments final by default and force you to specify if you want mutable. If we do make them implicitly final, there's no incentive to provide a non-final option - nobody has to have non-final method parameters. > -- Howard. > > Sent from my iPad > > On 20/12/2012, at 4:17 AM, Zhong Yu wrote: > >> On Wed, Dec 19, 2012 at 10:04 AM, Ricky Clarkson >> wrote: >>> I'd just like to raise one potential case for making it implicitly final: >>> >>> Iterable list = someNumbers.map(x -> x = 5); >>> >>> (If it really returns a Stream, Streamable, CanBeStreamed or >>> NotTonightDearImBusyStreaming, please give me some leeway.) >>> >>> The programmer is left wondering why the compiler says that map returns an >>> Iterable instead of an Iterable, and it's all because he >>> used = instead of ==. The programmer then wonders why Java didn't just give >>> him a compile error when he assigned to the parameter, after all assigning >>> to the parameter there is basically a no-op. >> >> Static analyzers can catch that. For example in IntelliJ >> >> int f(int x) { return x++; } >> >> will raise a noticeable warning: "The value changed at x++ is never used" >> >> int f(int x) { return x=5; } >> >> will raise a less noticeable warning: "the value 5 assigned to x is never used" >> >> I haven't tried lambda in IntelliJ 12, but hopefully the same analysis >> exists; maybe it should be stronger and louder for lambda expressions. >> >> Javac probably doesn't need to perform such analysis by default. >> >> Zhong Yu >> >> >>> >>> On Wed, Dec 19, 2012 at 1:44 PM, Zhong Yu wrote: >>>> >>>> On Tue, Dec 18, 2012 at 8:15 PM, Dan Smith >>>> wrote: >>>>> On Dec 18, 2012, at 5:43 PM, David Holmes >>>>> wrote: >>>>> >>>>>> I don't grok the problem. If the parameter is not modified then it is >>>>>> effectively final. Making parameters final is then only an >>>>>> error-detection mechanism, and I don't see that is warranted in lambda >>>>>> expressions. So I don't see "final by default" as warranted. >>>>>> >>>>>> Having to add back the inferred type to enable final to be added >>>>>> doesn't >>>>>> seem like a large burden. >>>>> >>>>> Yeah, I think I agree with David. The times when it seems most useful >>>>> to say "this parameter is final and I definitely don't want anyone changing >>>>> it" are when you've got a large lambda body, and then it's really not so >>>>> painful to give your parameters full declarations ('final String s'). >>>>> >>>>> It's worth noting that 'final' parameters and local variables didn't >>>>> exist in the original language and were only added to support the "captured >>>>> variables must be final" rule when anonymous/local classes were added. If >>>>> "effectively final" were an option back then (don't know if it's something >>>>> they thought about or not), I would bet we still wouldn't have 'final' >>>>> parameters and local variables. They're really a lot less useful than >>>>> 'final' fields -- because all interaction is in a single thread and within a >>>>> single block of code. >>>> >>>> Agreed, although most method parameters and many local variables are >>>> conceptually final, people don't bother to mark them final. >>>> >>>> Making method parameters implicitly final is inconsistent with >>>> existing practices; the benefit is dubious: >>>> >>>> If a programmer assigns a new value to a method parameter, and later >>>> reads it, it is very likely intentional, there's no need for alarm >>>> here. >>>> >>>> If a programmer assigns a new value to a method parameter, and never >>>> reads it, it is probably a mistake; fortunately IDEs will raise a >>>> warning for it. >>>> >>>> Zhong Yu >>>> >>>>> >>>>>> On the other hand can't the compiler accept >>>>>> parameter modifiers even if it infers the type? >>>>> >>>>> No, there are two syntax options: list of identifiers, or full method >>>>> parameter list. Less complex that way. >>>>> >>>>> ?Dan >> From robert.field at oracle.com Wed Dec 19 16:33:09 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Thu, 20 Dec 2012 00:33:09 +0000 Subject: hg: lambda/lambda/jdk: functionalInterfaceClass is the SAM interface, not the declaring type of the SAM Message-ID: <20121220003331.0CEA3472B0@hg.openjdk.java.net> Changeset: b02cda04c81c Author: rfield Date: 2012-12-19 16:32 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b02cda04c81c functionalInterfaceClass is the SAM interface, not the declaring type of the SAM ! src/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java From tom.hawtin at oracle.com Wed Dec 19 17:15:03 2012 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Thu, 20 Dec 2012 01:15:03 +0000 Subject: lambda expression parameters In-Reply-To: References: <6930E92B-352A-4616-B2CE-7BF03C3CF031@agiledeveloper.com> <50D0EEDF.60500@oracle.com> <50D10DC7.2090408@oracle.com> <9582DAB1-6D81-4422-A404-6ADD7380D2BA@gmail.com> Message-ID: <50D26697.4000401@oracle.com> On 19/12/2012 22:11, Talden wrote: > If Java were done over from scratch it would be tempting to flip it on it's > head an make everything implicitly final unless marked as a 'var'. Heck There's no reason why you can't do that now* for your own code without actually changing the language. Slap an @Var or, if you really don't like mutability, @Mutable on any variable you want to be non-final. I imagine it would be easy to modify javac or similar to do the checking. Tom *With the exception that you'll need final on variables for the soon-to-be-anomalous local class behaviour, final field semantics, compile-time constant inlining and reflection. From mike.duigou at oracle.com Wed Dec 19 19:04:07 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 19 Dec 2012 19:04:07 -0800 Subject: RFR : CR8004015 : Add parent interfaces and default methods to basic functional interfaces In-Reply-To: <50CE9D22.7060108@oracle.com> References: <99DC2763-ED44-42CA-90F3-04AD07B2846D@oracle.com> <50CAC719.7090308@oracle.com> <0A9D8113-780C-4BA7-9380-AAD53A0DAA58@oracle.com> <50CE9D22.7060108@oracle.com> Message-ID: <417F6F27-0175-4A7E-B2E6-9DCCE590D812@oracle.com> On Dec 16 2012, at 20:18 , David Holmes wrote: > On 15/12/2012 4:58 AM, Mike Duigou wrote: >> >> On Dec 13 2012, at 22:28 , David Holmes wrote: >> >>>> I have added @throws NPE for a number of the default methods. We won't be including @throws NPE in all cases where null is disallowed because when the @throws NPE is declared the API is required to throw NPE in that circumstance. So for cases where the NPE is "naturally" thrown or that aren't performance sensitive we will likely add @throws NPE declarations but for performance sensitive methods we won't be adding explicit null checks to match a @throws NPE specification. There's a tradeoff here in some cases. Please feel free to quibble about specific cases as they occur. :-) >>> >>> That doesn't make sense to me. The throwing of the NPE is intended to be part of the specification not an implementation choice. Further @param foo non-null, is just as binding on implementations as @throws NPE if foo is null. ??? >> >> An "@param foo non-null" by itself is not considered normative because it doesn't document what happens when null is passed. So it ends up being advisory only. An "@throws NPE" is considered normative and the implementation must throw in all circumstances described. > > Aside: that is an interesting interpretation but from whence does it come? From the TCK/JCK team. In communications with them to clarify the specification > It is non-normative by definition because it is incomplete? Yes. If a constraint is specified then it is only testable to the extent that the outcome of is also described. > Or is it just non-normative because it is an @param tag? No. > >> (Please bear with the step-by-step nature of the following sample, it's incremental pace is not meant to be insulting--it's a write-up for a general FAQ). If I have a method: > > But once you add the @throws the advisory of the @param is redundant. Hence to me it is an either/or situation. It does seem redundant to me but not entirely useless. I would prefer to not have to check the @throws declaration to know what the valid range is for a parameter. My tendency is to always try to consolidate all information about something in one place and if that's not practical then allow for some duplication. An example recently was information about the ForkJoin common pool. I prefer to see all the characteristics of the common pool described on the documentation for commonPool() method rather than disparately on shutdown(), etc. The advantage being that collecting it into one place allows be to completely understand (OK, within limits) the characteristics of common pool. Without the consolidation I may not even be able to find all of the documentation which references the common pool. There does seem to be some value though to duplicating the information to other places where it might be relevant. It's perhaps worthwhile to note in shutdown() that it is ignored for the common pool. > Further the advisory, being advisory, is useless in my opinion, so not something to use regardless. The advisories do still represent good advice for what to pass. Mike From benjamin.john.evans at gmail.com Thu Dec 20 07:33:57 2012 From: benjamin.john.evans at gmail.com (Ben Evans) Date: Thu, 20 Dec 2012 15:33:57 +0000 Subject: Build problems on Mac Message-ID: Hi, Current trunk is failing to build on Mac OS X 10.7 It gets a long way through the build and then fails with this: Compiling 856 files for BUILD_JOBJC Compiling 856 files for BUILD_JOBJC_HEADERS javac: invalid flag: -Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-auxiliaryclass Usage: javac use -help for a list of possible options make[2]: *** [/Users/boxcat/projects/lambda/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes/_the.batch] Error 2 make[2]: *** Waiting for unfinished jobs.... Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. make[1]: *** [classes-only] Error 2 make: *** [jdk-only] Error 2 ariel-2:makefiles boxcat$ I'm going to dig into it & see what I can find, but figured it was worth a mail here to see if anyone else has encountered this problem. Thanks, Ben From brian.goetz at oracle.com Thu Dec 20 07:43:23 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 20 Dec 2012 15:43:23 +0000 Subject: hg: lambda/lambda/jdk: Eliminate pull mode traversal of streams. Message-ID: <20121220154334.CC5B7472D9@hg.openjdk.java.net> Changeset: 1c575e8dad2e Author: briangoetz Date: 2012-12-20 10:42 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/1c575e8dad2e Eliminate pull mode traversal of streams. All wrapIterator methods are gone. Short-circuit terminal ops (and iterator()) now work by wrapping an iterator around the (source iterator, sink chain) with a buffer at the end to catch results, and dispensing those from iterator. Short-circuit intermediate ops (such as limit) work by adding a feedback channel in Sink. Contributed-by: paul.sandoz at oracle.com Contributed-by: brian.goetz at oracle.com ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/PipelineHelper.java ! src/share/classes/java/util/stream/Sink.java ! src/share/classes/java/util/stream/StreamShape.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/op/CollectorOps.java ! src/share/classes/java/util/stream/op/ConcurrentTabulateOp.java ! src/share/classes/java/util/stream/op/CumulateOp.java ! src/share/classes/java/util/stream/op/FilterOp.java ! src/share/classes/java/util/stream/op/FindOp.java ! src/share/classes/java/util/stream/op/FlagDeclaringOp.java ! src/share/classes/java/util/stream/op/FoldOp.java ! src/share/classes/java/util/stream/op/ForEachOp.java ! src/share/classes/java/util/stream/op/IntermediateOp.java ! src/share/classes/java/util/stream/op/MapOp.java ! src/share/classes/java/util/stream/op/MatchOp.java ! src/share/classes/java/util/stream/op/MultiMapOp.java ! src/share/classes/java/util/stream/op/SliceOp.java ! src/share/classes/java/util/stream/op/SortedOp.java ! src/share/classes/java/util/stream/op/SpinedBuffer.java ! src/share/classes/java/util/stream/op/TeeOp.java ! src/share/classes/java/util/stream/op/UniqOp.java ! src/share/classes/java/util/stream/primitive/IntAverageOp.java ! src/share/classes/java/util/stream/primitive/IntCumulateOp.java ! src/share/classes/java/util/stream/primitive/IntFilterOp.java ! src/share/classes/java/util/stream/primitive/IntFoldOp.java ! src/share/classes/java/util/stream/primitive/IntMapOp.java ! src/share/classes/java/util/stream/primitive/IntMultiMapOp.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java ! src/share/classes/java/util/stream/primitive/IntTeeOp.java ! src/share/classes/java/util/stream/primitive/IntToIntegerOp.java ! src/share/classes/java/util/stream/primitive/PrimitiveNodes.java ! src/share/classes/java/util/stream/primitive/RefToIntMapOp.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlagOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MultiMapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SliceOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SortedOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/TeeOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/TestFlagExpectedOp.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntMultiMapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntSliceOpTest.java From paul.sandoz at oracle.com Thu Dec 20 07:44:02 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 20 Dec 2012 16:44:02 +0100 Subject: Build problems on Mac In-Reply-To: References: Message-ID: <8DB52AF6-8D00-46C5-B195-B847B01A9F6F@oracle.com> Hi, I encounter that all the time, whereas some others do not. We have not gotten down to the reasons why, although other JDK repos do not have this fix the last time i looked so i don't really know why it is required only for the lambda JDK repo. See below for a patch. Paul. diff -r 433c67388856 makefiles/Setup.gmk --- a/makefiles/Setup.gmk Mon Dec 10 23:19:19 2012 -0500 +++ b/makefiles/Setup.gmk Tue Dec 11 13:57:58 2012 +0100 @@ -27,7 +27,7 @@ JAVAH_JARS ?= "-Xbootclasspath/p:$(LANGTOOLS_OUTPUTDIR)/dist/bootstrap/lib/javah.jar" -jar $(LANGTOOLS_OUTPUTDIR)/dist/bootstrap/lib/javah.jar JAVADOC_JARS ?= "-Xbootclasspath/p:$(LANGTOOLS_OUTPUTDIR)/dist/bootstrap/lib/javadoc.jar" -jar $(LANGTOOLS_OUTPUTDIR)/dist/bootstrap/lib/javadoc.jar -DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-auxiliaryclass +DISABLE_WARNINGS:=-Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally # The generate old bytecode javac setup uses the new compiler to compile for the # boot jdk to generate tools that need to be run with the boot jdk. On Dec 20, 2012, at 4:33 PM, Ben Evans wrote: > Hi, > > Current trunk is failing to build on Mac OS X 10.7 > > It gets a long way through the build and then fails with this: > > Compiling 856 files for BUILD_JOBJC > Compiling 856 files for BUILD_JOBJC_HEADERS > javac: invalid flag: > -Xlint:all,-deprecation,-unchecked,-rawtypes,-cast,-serial,-dep-ann,-static,-fallthrough,-try,-varargs,-empty,-finally,-auxiliaryclass > Usage: javac > use -help for a list of possible options > make[2]: *** [/Users/boxcat/projects/lambda/build/macosx-x86_64-normal-server-release/jdk/jobjc_classes/_the.batch] > Error 2 > make[2]: *** Waiting for unfinished jobs.... > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > make[1]: *** [classes-only] Error 2 > make: *** [jdk-only] Error 2 > ariel-2:makefiles boxcat$ > > I'm going to dig into it & see what I can find, but figured it was > worth a mail here to see if anyone else has encountered this problem. > > Thanks, > > Ben > From paul.sandoz at oracle.com Thu Dec 20 08:12:51 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 20 Dec 2012 16:12:51 +0000 Subject: hg: lambda/lambda/jdk: IntStream.min/max return Optional Message-ID: <20121220161303.C2A36472DB@hg.openjdk.java.net> Changeset: 41cd9ddd0a16 Author: psandoz Date: 2012-12-20 17:12 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/41cd9ddd0a16 IntStream.min/max return Optional ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntStream.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntMinMaxTest.java From brian.goetz at oracle.com Thu Dec 20 08:54:27 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 20 Dec 2012 16:54:27 +0000 Subject: hg: lambda/lambda/jdk: 3 new changesets Message-ID: <20121220165500.C08F0472DF@hg.openjdk.java.net> Changeset: 4687d742ff42 Author: briangoetz Date: 2012-12-20 10:51 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/4687d742ff42 Pull min/max implementation up into Stream ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/op/ForEachOp.java ! src/share/classes/java/util/stream/op/IntermediateOp.java Changeset: 2ea8e646510a Author: briangoetz Date: 2012-12-20 11:54 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2ea8e646510a Inline {Filter,Map,FlatMap,Tee}Op directly into ReferencePipeline - src/share/classes/java/util/Iterables.java ! src/share/classes/java/util/stream/ReferencePipeline.java - src/share/classes/java/util/stream/op/FilterOp.java - src/share/classes/java/util/stream/op/MapOp.java - src/share/classes/java/util/stream/op/MultiMapOp.java + src/share/classes/java/util/stream/op/Ops.java - src/share/classes/java/util/stream/op/TeeOp.java - test-ng/tests/org/openjdk/tests/java/util/IterablesTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MultiMapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/TeeOpTest.java Changeset: 6f0f4b8270fc Author: briangoetz Date: 2012-12-20 11:54 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6f0f4b8270fc Merge From brian.goetz at oracle.com Thu Dec 20 09:29:35 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 20 Dec 2012 17:29:35 +0000 Subject: hg: lambda/lambda/jdk: Inline Int{Filter, Map, FlatMap, Tee, ToInteger}Op directly into IntPipeline Message-ID: <20121220172947.026FC472E5@hg.openjdk.java.net> Changeset: 5c3e950c5302 Author: briangoetz Date: 2012-12-20 12:29 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5c3e950c5302 Inline Int{Filter,Map,FlatMap,Tee,ToInteger}Op directly into IntPipeline ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/op/Ops.java ! src/share/classes/java/util/stream/primitive/IntAverageOp.java - src/share/classes/java/util/stream/primitive/IntFilterOp.java - src/share/classes/java/util/stream/primitive/IntMapOp.java - src/share/classes/java/util/stream/primitive/IntMultiMapOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java - src/share/classes/java/util/stream/primitive/IntTeeOp.java - src/share/classes/java/util/stream/primitive/IntToIntegerOp.java From paul.sandoz at oracle.com Thu Dec 20 10:15:15 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 20 Dec 2012 18:15:15 +0000 Subject: hg: lambda/lambda/jdk: IntOptional and use on IntStream. Message-ID: <20121220181542.4E866472EE@hg.openjdk.java.net> Changeset: daf32df5cfe3 Author: psandoz Date: 2012-12-20 19:14 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/daf32df5cfe3 IntOptional and use on IntStream. ! src/share/classes/java/util/stream/op/FindOp.java ! src/share/classes/java/util/stream/primitive/IntAverageOp.java ! src/share/classes/java/util/stream/primitive/IntFoldOp.java + src/share/classes/java/util/stream/primitive/IntOptional.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntStream.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindAnyOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindFirstOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntMinMaxTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntReduceTest.java From paul.sandoz at oracle.com Thu Dec 20 10:26:47 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 20 Dec 2012 18:26:47 +0000 Subject: hg: lambda/lambda/jdk: Move to default impls on iface. Message-ID: <20121220182715.4C7DC472EF@hg.openjdk.java.net> Changeset: 20a8ee9ce538 Author: psandoz Date: 2012-12-20 19:25 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/20a8ee9ce538 Move to default impls on iface. ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntStream.java From robert.field at oracle.com Thu Dec 20 12:49:51 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Thu, 20 Dec 2012 20:49:51 +0000 Subject: hg: lambda/lambda/langtools: Add full type signature generation functionality, as needed for method signatures, and correct generation of inner class signatures Message-ID: <20121220204956.83B2347300@hg.openjdk.java.net> Changeset: 1faa2226c00e Author: rfield Date: 2012-12-19 16:39 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/1faa2226c00e Add full type signature generation functionality, as needed for method signatures, and correct generation of inner class signatures ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java From mike.duigou at oracle.com Thu Dec 20 12:56:46 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 20 Dec 2012 20:56:46 +0000 Subject: hg: lambda/lambda/jdk: add missing BiPredicate impls and javadoc cleanup Message-ID: <20121220205709.2EA3B47301@hg.openjdk.java.net> Changeset: b7bffe61f5b9 Author: mduigou Date: 2012-12-20 12:54 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b7bffe61f5b9 add missing BiPredicate impls and javadoc cleanup ! src/share/classes/java/util/function/BiPredicate.java ! src/share/classes/java/util/function/DoubleBinaryOperator.java ! src/share/classes/java/util/function/DoubleFunction.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/IntFunction.java ! src/share/classes/java/util/function/LongFunction.java From brian.goetz at oracle.com Thu Dec 20 12:58:04 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 20 Dec 2012 20:58:04 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121220205827.7554C47302@hg.openjdk.java.net> Changeset: 05308d5e0fe9 Author: briangoetz Date: 2012-12-20 15:57 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/05308d5e0fe9 More tabulators ! src/share/classes/java/util/stream/reduce/Tabulators.java ! test-ng/tests/org/openjdk/tests/java/util/stream/TabulatorsTest.java Changeset: 597f255db658 Author: briangoetz Date: 2012-12-20 15:57 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/597f255db658 Merge From brian.goetz at oracle.com Thu Dec 20 14:00:39 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 20 Dec 2012 22:00:39 +0000 Subject: hg: lambda/lambda/jdk: Additional runtime support for serialized lambdas, plus tests. NOTE: 1 failing test case. Message-ID: <20121220220050.8799347307@hg.openjdk.java.net> Changeset: bde4cb561b72 Author: briangoetz Date: 2012-12-20 17:00 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bde4cb561b72 Additional runtime support for serialized lambdas, plus tests. NOTE: 1 failing test case. ! src/share/classes/java/lang/invoke/SerializedLambda.java ! test-ng/tests/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java + test-ng/tests/org/openjdk/tests/java/lang/invoke/TestDeserializeMethod.java From brian.goetz at oracle.com Thu Dec 20 14:08:56 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 20 Dec 2012 22:08:56 +0000 Subject: hg: lambda/lambda/jdk: Rename test to match naming convention Message-ID: <20121220220907.E552B47308@hg.openjdk.java.net> Changeset: 6e0aebb8a486 Author: briangoetz Date: 2012-12-20 17:08 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6e0aebb8a486 Rename test to match naming convention = test-ng/tests/org/openjdk/tests/java/lang/invoke/DeserializeMethodTest.java < test-ng/tests/org/openjdk/tests/java/lang/invoke/TestDeserializeMethod.java From mike.duigou at oracle.com Thu Dec 20 15:20:31 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 20 Dec 2012 23:20:31 +0000 Subject: hg: lambda/lambda/jdk: docs corrections Message-ID: <20121220232043.617BC4730A@hg.openjdk.java.net> Changeset: 8d740d926ced Author: mduigou Date: 2012-12-20 15:20 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/8d740d926ced docs corrections ! src/share/classes/java/util/function/BiBlock.java ! src/share/classes/java/util/function/BiFunction.java ! src/share/classes/java/util/function/BiPredicate.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/LongFunction.java From brian.goetz at oracle.com Thu Dec 20 16:06:43 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 21 Dec 2012 00:06:43 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121221000706.C74CA4730B@hg.openjdk.java.net> Changeset: acf1f442db8f Author: briangoetz Date: 2012-12-20 19:06 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/acf1f442db8f Inline ConcurrentTabulateOp, ToArrayOp, and RefToIntMapOp into Pipeline classes ! src/share/classes/java/util/stream/ReferencePipeline.java - src/share/classes/java/util/stream/op/ConcurrentTabulateOp.java ! src/share/classes/java/util/stream/op/Ops.java - src/share/classes/java/util/stream/op/ToArrayOp.java - src/share/classes/java/util/stream/primitive/RefToIntMapOp.java Changeset: 70883a722478 Author: briangoetz Date: 2012-12-20 19:06 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/70883a722478 Merge From brian.goetz at oracle.com Thu Dec 20 16:55:04 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 21 Dec 2012 00:55:04 +0000 Subject: hg: lambda/lambda/jdk: Inline more ops Message-ID: <20121221005517.B33EE47315@hg.openjdk.java.net> Changeset: f2ed433a8f33 Author: briangoetz Date: 2012-12-20 19:54 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f2ed433a8f33 Inline more ops ! src/share/classes/java/util/stream/primitive/IntPipeline.java - src/share/classes/java/util/stream/primitive/IntToArrayOp.java From mike.duigou at oracle.com Thu Dec 20 17:41:14 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 20 Dec 2012 17:41:14 -0800 Subject: RFR: CR#8004561 : Additional Functional Interfaces and Updates Message-ID: Hello all; Here are some additional functional interfaces for review. The additions fill in holes for primitive types and for two operand "Bi" operations. http://cr.openjdk.java.net/~mduigou/8004561/0/webrev/ http://cr.openjdk.java.net/~mduigou/8004561/0/specdiff/java/util/function/package-summary.html Additionally, this patch contains naming updates on the existing functional interfaces following 335 EG review. It does not include the interface specializations and default methods previously proposed in CR#8004015. That proposal has been withdrawn. It turned out that user errors involving unexpected boxing were just too common for the value provided. Mike From howard.lovatt at gmail.com Thu Dec 20 18:07:21 2012 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Fri, 21 Dec 2012 13:07:21 +1100 Subject: RFR: CR#8004561 : Additional Functional Interfaces and Updates In-Reply-To: References: Message-ID: 1. DoubleBlock doesn't extend Block and doesn't have a default method, similarly int and long 2. Similarly all the rest like Function aren't extended Is this the correct link - it seems to have gone backwards? -- Howard. On 21 December 2012 12:41, Mike Duigou wrote: > Hello all; > > Here are some additional functional interfaces for review. The additions > fill in holes for primitive types and for two operand "Bi" operations. > > http://cr.openjdk.java.net/~mduigou/8004561/0/webrev/ > > http://cr.openjdk.java.net/~mduigou/8004561/0/specdiff/java/util/function/package-summary.html > > Additionally, this patch contains naming updates on the existing > functional interfaces following 335 EG review. It does not include the > interface specializations and default methods previously proposed in > CR#8004015. That proposal has been withdrawn. It turned out that user > errors involving unexpected boxing were just too common for the value > provided. > > Mike > > -- -- Howard. From henry.jen at oracle.com Thu Dec 20 22:28:08 2012 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 20 Dec 2012 22:28:08 -0800 Subject: RFR: JDK-8005263: Logging APIs takes Supplier for message Message-ID: <50D40178.3060604@oracle.com> Hi, This patch adds a couple APIs to java.util.logging.Logger so that construction of log messages only occurs when it is actually to be logged by using Supplier instead of String. Since the idea is to avoid unnecessary construction of log messages, thus APIs imply formatting are not provided. Thus all forms of logrb and log with Parameters are not included. log with Throwable are named to be logEx or logpEx to avoid null ambiguous as it seems like it's quite common usage with logger.log(level, null, thrown) Specdiff and webrev can be found at following, http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/specdiff/diff.html http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/webrev/ Cheers, Henry From robert.field at oracle.com Thu Dec 20 23:13:24 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 21 Dec 2012 07:13:24 +0000 Subject: hg: lambda/lambda/jdk: Update FILES_java.gmk: remove java/util/Iterables Message-ID: <20121221071350.66E8247327@hg.openjdk.java.net> Changeset: 7ad5a1c22a84 Author: rfield Date: 2012-12-20 23:12 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7ad5a1c22a84 Update FILES_java.gmk: remove java/util/Iterables ! make/java/java/FILES_java.gmk From peter.levart at gmail.com Fri Dec 21 01:04:09 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 21 Dec 2012 10:04:09 +0100 Subject: RFR: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50D40178.3060604@oracle.com> References: <50D40178.3060604@oracle.com> Message-ID: <50D42609.10200@gmail.com> Hi Henry, Have you considered reversing the positions of Supplier and Throwable arguments in methods that take both? For example instead of: 695 public void logEx(Level level, Supplier msgSupplier, Throwable thrown) { the following: 695 public void logEx(Level level,Throwable thrown, Supplier msgSupplier) { If one chooses this form (taking Throwable and Supplier) it might be because there is some code in the lambda expression that is turned into Suppier that spans multiple lines. Better compact multi-line formatting is possible if lambda is last argument: logger.logEx( Level.WARN, () -> { StringBuilder sb = new StringBuilder(); for (Foo foo : foos) { sb.append(sb.length() == 0 ? "[" : ","); sb.append(foo); } if (sb.length() > 0) sb.append("]"); return sb.toString(); }, exception ); vs. logger.logEx(Level.WARN, exception, () -> { StringBuilder sb = new StringBuilder(); for (Foo foo : foos) { sb.append(sb.length() == 0 ? "[" : ","); sb.append(foo); } if (sb.length() > 0) sb.append("]"); return sb.toString(); }); It might be (haven't checked) that you don't need another name for a method (logEx) in that case too. Regards, Peter On 12/21/2012 07:28 AM, Henry Jen wrote: > Hi, > > This patch adds a couple APIs to java.util.logging.Logger so that > construction of log messages only occurs when it is actually to be > logged by using Supplier instead of String. > > Since the idea is to avoid unnecessary construction of log messages, > thus APIs imply formatting are not provided. Thus all forms of logrb and > log with Parameters are not included. > > log with Throwable are named to be logEx or logpEx to avoid null > ambiguous as it seems like it's quite common usage with > > logger.log(level, null, thrown) > > Specdiff and webrev can be found at following, > > http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/specdiff/diff.html > http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/webrev/ > > Cheers, > Henry From Alan.Bateman at oracle.com Fri Dec 21 01:22:44 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 21 Dec 2012 09:22:44 +0000 Subject: RFR: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50D40178.3060604@oracle.com> References: <50D40178.3060604@oracle.com> Message-ID: <50D42A64.3050804@oracle.com> On 21/12/2012 06:28, Henry Jen wrote: > Hi, > > This patch adds a couple APIs to java.util.logging.Logger so that > construction of log messages only occurs when it is actually to be > logged by using Supplier instead of String. > > Since the idea is to avoid unnecessary construction of log messages, > thus APIs imply formatting are not provided. Thus all forms of logrb and > log with Parameters are not included. > > log with Throwable are named to be logEx or logpEx to avoid null > ambiguous as it seems like it's quite common usage with > > logger.log(level, null, thrown) > > Specdiff and webrev can be found at following, > > http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/specdiff/diff.html > http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/webrev/ > > Cheers, > Henry Henry - just a quick comment on the class description. I think it would be better not to include the sentence "Since 1.8 ..." as it that will quickly become a historical note. It would be much better (in my view) to just highlight the methods with something like "Several of the methods take a Supplier function ..." and make the potential performance benefit of using these methods clear. -Alan. From paul.sandoz at oracle.com Fri Dec 21 02:21:59 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 21 Dec 2012 10:21:59 +0000 Subject: hg: lambda/lambda/jdk: - Use spliterator size estimation to calculate target size. Message-ID: <20121221102221.05A8E4732E@hg.openjdk.java.net> Changeset: 0c7fb8d0ae93 Author: psandoz Date: 2012-12-21 11:21 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0c7fb8d0ae93 - Use spliterator size estimation to calculate target size. - Test that monitors if splitting occurs or not. ! src/share/classes/java/util/stream/AbstractPipeline.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java From forax at univ-mlv.fr Fri Dec 21 04:28:49 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 21 Dec 2012 13:28:49 +0100 Subject: RFR: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50D42A64.3050804@oracle.com> References: <50D40178.3060604@oracle.com> <50D42A64.3050804@oracle.com> Message-ID: <50D45601.10501@univ-mlv.fr> On 12/21/2012 10:22 AM, Alan Bateman wrote: > On 21/12/2012 06:28, Henry Jen wrote: >> Hi, >> >> This patch adds a couple APIs to java.util.logging.Logger so that >> construction of log messages only occurs when it is actually to be >> logged by using Supplier instead of String. >> >> Since the idea is to avoid unnecessary construction of log messages, >> thus APIs imply formatting are not provided. Thus all forms of logrb and >> log with Parameters are not included. >> >> log with Throwable are named to be logEx or logpEx to avoid null >> ambiguous as it seems like it's quite common usage with >> >> logger.log(level, null, thrown) >> >> Specdiff and webrev can be found at following, >> >> http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/specdiff/diff.html >> http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/webrev/ >> >> Cheers, >> Henry > Henry - just a quick comment on the class description. I think it would > be better not to include the sentence "Since 1.8 ..." as it that will > quickly become a historical note. It would be much better (in my view) > to just highlight the methods with something like "Several of the > methods take a Supplier function ..." and make the potential performance > benefit of using these methods clear. > > -Alan. > You should also add a note saying that the supplier can be specified as a lambda and in that case, the lambda *must* not capture value of local variable, otherwise a supplier object will be created each time you log something. R?mi From peter.levart at gmail.com Fri Dec 21 05:47:28 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 21 Dec 2012 14:47:28 +0100 Subject: RFR: CR#8004561 : Additional Functional Interfaces and Updates In-Reply-To: References: Message-ID: <50D46870.6060808@gmail.com> I see that (given Function f, g), f.compose(g) means: f?g, rather than f?g. Would mathematicians complain? :-) Regards, Peter On 12/21/2012 02:41 AM, Mike Duigou wrote: > Hello all; > > Here are some additional functional interfaces for review. The additions fill in holes for primitive types and for two operand "Bi" operations. > > http://cr.openjdk.java.net/~mduigou/8004561/0/webrev/ > http://cr.openjdk.java.net/~mduigou/8004561/0/specdiff/java/util/function/package-summary.html > > Additionally, this patch contains naming updates on the existing functional interfaces following 335 EG review. It does not include the interface specializations and default methods previously proposed in CR#8004015. That proposal has been withdrawn. It turned out that user errors involving unexpected boxing were just too common for the value provided. > > Mike From brian.goetz at oracle.com Fri Dec 21 08:12:01 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 21 Dec 2012 16:12:01 +0000 Subject: hg: lambda/lambda/jdk: Simplifications in StreamShape; inline away FlagDeclaringOp Message-ID: <20121221161247.EA6D347336@hg.openjdk.java.net> Changeset: ff083b8a4477 Author: briangoetz Date: 2012-12-21 11:11 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ff083b8a4477 Simplifications in StreamShape; inline away FlagDeclaringOp ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/StreamShape.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/StreamSource.java ! src/share/classes/java/util/stream/op/FindOp.java - src/share/classes/java/util/stream/op/FlagDeclaringOp.java ! src/share/classes/java/util/stream/op/ForEachOp.java ! src/share/classes/java/util/stream/op/IntermediateOp.java ! src/share/classes/java/util/stream/op/MatchOp.java ! src/share/classes/java/util/stream/op/Ops.java ! src/share/classes/java/util/stream/op/SliceOp.java ! src/share/classes/java/util/stream/op/StreamOp.java ! src/share/classes/java/util/stream/primitive/IntCollectorOps.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/PrimitiveOps.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java + test-ng/tests/org/openjdk/tests/java/util/stream/op/FlagDeclaringOp.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SpinedBufferTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/TestFlagExpectedOp.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java From zhong.j.yu at gmail.com Fri Dec 21 09:09:28 2012 From: zhong.j.yu at gmail.com (Zhong Yu) Date: Fri, 21 Dec 2012 11:09:28 -0600 Subject: RFR: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50D40178.3060604@oracle.com> References: <50D40178.3060604@oracle.com> Message-ID: Question: why not delay the evaluation of the message even further, until LogRecord.getMessage() is invoked? Since a logger might be enabled for the level, but the handler is not, so the message is not really logged. Or is that considered uncommon? On Fri, Dec 21, 2012 at 12:28 AM, Henry Jen wrote: > Hi, > > This patch adds a couple APIs to java.util.logging.Logger so that > construction of log messages only occurs when it is actually to be > logged by using Supplier instead of String. > > Since the idea is to avoid unnecessary construction of log messages, > thus APIs imply formatting are not provided. Thus all forms of logrb and > log with Parameters are not included. > > log with Throwable are named to be logEx or logpEx to avoid null > ambiguous as it seems like it's quite common usage with > > logger.log(level, null, thrown) > > Specdiff and webrev can be found at following, > > http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/specdiff/diff.html > http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/webrev/ > > Cheers, > Henry From paul.sandoz at oracle.com Fri Dec 21 09:20:03 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 21 Dec 2012 17:20:03 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121221172027.BF8F647338@hg.openjdk.java.net> Changeset: aae1c6b14273 Author: psandoz Date: 2012-12-21 18:19 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/aae1c6b14273 - mutable reduce for int stream - count and sum mutable reducer for calculating arithmetic mean - optional double/long classes. + src/share/classes/java/util/stream/primitive/DoubleOptional.java - src/share/classes/java/util/stream/primitive/IntAverageOp.java ! src/share/classes/java/util/stream/primitive/IntFoldOp.java + src/share/classes/java/util/stream/primitive/IntMutableReducer.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntStream.java + src/share/classes/java/util/stream/primitive/LongOptional.java Changeset: a7a190cba436 Author: psandoz Date: 2012-12-21 18:19 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a7a190cba436 - Simplify forEach methods on pushing iterators and wrapping spliterators. - Optimize {Int}SpinedBufffer for use with pushing iterators. - Optimize looping when short-circuit op is present. ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/PipelineHelper.java ! src/share/classes/java/util/stream/StreamShape.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/op/SpinedBuffer.java ! src/share/classes/java/util/stream/primitive/IntSpinedBuffer.java From peter.levart at gmail.com Fri Dec 21 09:52:48 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 21 Dec 2012 18:52:48 +0100 Subject: RFR: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50D40178.3060604@oracle.com> References: <50D40178.3060604@oracle.com> Message-ID: <50D4A1F0.4090206@gmail.com> Hi Henry, again, To delay constructing message to as late as possible, you could construct a LogRecord with a reference to Supplier and only evaluate the Supplier on the first call to LogRecord.getMessage() and then cache-it. Like the following: http://dl.dropbox.com/u/101777488/jdk8-tl/LogRecord/webrev/index.html Also, the "staging" Block call-back in doLog() is a very nice lambda usage, but it comes with a cost of constructing another lambda object for each call to those methods... Regards, Peter On 12/21/2012 07:28 AM, Henry Jen wrote: > Hi, > > This patch adds a couple APIs to java.util.logging.Logger so that > construction of log messages only occurs when it is actually to be > logged by using Supplier instead of String. > > Since the idea is to avoid unnecessary construction of log messages, > thus APIs imply formatting are not provided. Thus all forms of logrb and > log with Parameters are not included. > > log with Throwable are named to be logEx or logpEx to avoid null > ambiguous as it seems like it's quite common usage with > > logger.log(level, null, thrown) > > Specdiff and webrev can be found at following, > > http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/specdiff/diff.html > http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/webrev/ > > Cheers, > Henry From brian.goetz at oracle.com Fri Dec 21 11:08:01 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 21 Dec 2012 19:08:01 +0000 Subject: hg: lambda/lambda/jdk: Consolidate Collector Ops; move primitive specializations of {Intermediate,Stateful,Terminal}Op into nested classes of parent (e.g., StatefulOp.OfInt) Message-ID: <20121221190839.A8DD54734B@hg.openjdk.java.net> Changeset: bf8b93926752 Author: briangoetz Date: 2012-12-21 14:07 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/bf8b93926752 Consolidate Collector Ops; move primitive specializations of {Intermediate,Stateful,Terminal}Op into nested classes of parent (e.g., StatefulOp.OfInt) ! src/share/classes/java/util/stream/op/CollectorOps.java ! src/share/classes/java/util/stream/op/IntermediateOp.java ! src/share/classes/java/util/stream/op/Ops.java ! src/share/classes/java/util/stream/op/StatefulOp.java ! src/share/classes/java/util/stream/op/TerminalOp.java - src/share/classes/java/util/stream/primitive/IntCollectorOps.java ! src/share/classes/java/util/stream/primitive/IntCumulateOp.java ! src/share/classes/java/util/stream/primitive/IntFoldOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java - src/share/classes/java/util/stream/primitive/PrimitiveOps.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SortedOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UniqOpTest.java From brian.goetz at oracle.com Fri Dec 21 11:21:04 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 21 Dec 2012 19:21:04 +0000 Subject: hg: lambda/lambda/jdk: Default methods on Map: putIfAbsent, remove, replace, computeIfAbsent, computeIfPresent, compute, merge. Message-ID: <20121221192115.B2F0B4734C@hg.openjdk.java.net> Changeset: 762326151ec6 Author: briangoetz Date: 2012-12-21 14:18 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/762326151ec6 Default methods on Map: putIfAbsent, remove, replace, computeIfAbsent, computeIfPresent, compute, merge. Contributed-by: dl ! src/share/classes/java/util/Map.java From brian.goetz at oracle.com Fri Dec 21 12:19:56 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 21 Dec 2012 20:19:56 +0000 Subject: hg: lambda/lambda/jdk: Use new Map methods in Tabulators Message-ID: <20121221202010.703B34734D@hg.openjdk.java.net> Changeset: b7b190b2ea01 Author: briangoetz Date: 2012-12-21 15:19 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b7b190b2ea01 Use new Map methods in Tabulators ! src/share/classes/java/util/stream/reduce/ConcurrentTabulators.java ! src/share/classes/java/util/stream/reduce/Tabulators.java From brian.goetz at oracle.com Fri Dec 21 12:27:56 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 21 Dec 2012 20:27:56 +0000 Subject: hg: lambda/lambda/jdk: Add additional type information so as to render compileable with b68 compiler Message-ID: <20121221202807.CF8794734E@hg.openjdk.java.net> Changeset: 66b10dba5989 Author: briangoetz Date: 2012-12-21 15:27 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/66b10dba5989 Add additional type information so as to render compileable with b68 compiler ! src/share/classes/java/util/stream/reduce/Reducers.java ! src/share/classes/java/util/stream/reduce/Tabulators.java From brian.goetz at oracle.com Fri Dec 21 13:31:40 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 21 Dec 2012 21:31:40 +0000 Subject: hg: lambda/lambda/jdk: Remove cumulate() Message-ID: <20121221213201.5FF2947353@hg.openjdk.java.net> Changeset: 322fa1bf4926 Author: briangoetz Date: 2012-12-21 16:28 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/322fa1bf4926 Remove cumulate() ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java - src/share/classes/java/util/stream/op/CumulateOp.java - src/share/classes/java/util/stream/primitive/IntCumulateOp.java ! src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntStream.java - test-ng/tests/org/openjdk/tests/java/util/stream/op/CumulateOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java - test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntCumulateOpTest.java From peter.levart at gmail.com Fri Dec 21 13:37:05 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 21 Dec 2012 22:37:05 +0100 Subject: RFR: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50D4A1F0.4090206@gmail.com> References: <50D40178.3060604@oracle.com> <50D4A1F0.4090206@gmail.com> Message-ID: <50D4D681.3040009@gmail.com> On 12/21/2012 06:52 PM, Peter Levart wrote: > Hi Henry, again, > > To delay constructing message to as late as possible, you could > construct a LogRecord with a reference to Supplier and only > evaluate the Supplier on the first call to LogRecord.getMessage() and > then cache-it. Like the following: > > http://dl.dropbox.com/u/101777488/jdk8-tl/LogRecord/webrev/index.html > On a second thought, the above might not be a good idea. The message should be materialized before passing the LogRecord to a handler, since some handlers might evaluate message in a special "logging" thread and therefore invoking a user provided Supplier in another thread might have undesirable effects (threading issues)... Regards, Peter > Also, the "staging" Block call-back in doLog() is a very nice lambda > usage, but it comes with a cost of constructing another lambda object > for each call to those methods... > > Regards, Peter > > On 12/21/2012 07:28 AM, Henry Jen wrote: >> Hi, >> >> This patch adds a couple APIs to java.util.logging.Logger so that >> construction of log messages only occurs when it is actually to be >> logged by using Supplier instead of String. >> >> Since the idea is to avoid unnecessary construction of log messages, >> thus APIs imply formatting are not provided. Thus all forms of logrb and >> log with Parameters are not included. >> >> log with Throwable are named to be logEx or logpEx to avoid null >> ambiguous as it seems like it's quite common usage with >> >> logger.log(level, null, thrown) >> >> Specdiff and webrev can be found at following, >> >> http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/specdiff/diff.html >> http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/webrev/ >> >> Cheers, >> Henry > From brian.goetz at oracle.com Fri Dec 21 14:10:20 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 21 Dec 2012 22:10:20 +0000 Subject: hg: lambda/lambda/jdk: Misc cleanups Message-ID: <20121221221032.1E4B247356@hg.openjdk.java.net> Changeset: 9bb56b3cc692 Author: briangoetz Date: 2012-12-21 17:10 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/9bb56b3cc692 Misc cleanups ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/StringJoiner.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/op/UniqOp.java ! src/share/classes/java/util/stream/primitive/PrimitiveNodes.java ! src/share/classes/java/util/stream/reduce/Tabulators.java From brian.goetz at oracle.com Fri Dec 21 14:47:31 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 21 Dec 2012 22:47:31 +0000 Subject: hg: lambda/lambda/jdk: Renamings and reorganizations, mostly away from .primitive package into desired target locations Message-ID: <20121221224742.B43C74735B@hg.openjdk.java.net> Changeset: 34d14e377743 Author: briangoetz Date: 2012-12-21 17:47 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/34d14e377743 Renamings and reorganizations, mostly away from .primitive package into desired target locations + src/share/classes/java/util/OptionalDouble.java + src/share/classes/java/util/OptionalInt.java + src/share/classes/java/util/OptionalLong.java + src/share/classes/java/util/function/IntMultiFunction.java + src/share/classes/java/util/stream/IntPipeline.java + src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/java/util/stream/StreamShape.java ! src/share/classes/java/util/stream/op/FindOp.java - src/share/classes/java/util/stream/primitive/DoubleOptional.java ! src/share/classes/java/util/stream/primitive/IntFoldOp.java - src/share/classes/java/util/stream/primitive/IntMultiFunction.java - src/share/classes/java/util/stream/primitive/IntMutableReducer.java ! src/share/classes/java/util/stream/primitive/IntNodes.java - src/share/classes/java/util/stream/primitive/IntOptional.java - src/share/classes/java/util/stream/primitive/IntPipeline.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java - src/share/classes/java/util/stream/primitive/IntStream.java - src/share/classes/java/util/stream/primitive/LongOptional.java ! src/share/classes/java/util/stream/reduce/MutableReducer.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamLinkTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamReuseTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindAnyOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindFirstOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MatchOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntMinMaxTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntMultiMapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntReduceTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java From pbenedict at apache.org Fri Dec 21 14:52:36 2012 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 21 Dec 2012 16:52:36 -0600 Subject: hg: lambda/lambda/jdk: Renamings and reorganizations, mostly away from .primitive package into desired target locations In-Reply-To: <20121221224742.B43C74735B@hg.openjdk.java.net> References: <20121221224742.B43C74735B@hg.openjdk.java.net> Message-ID: Ahh, I thought the "primitive" package was ingenious. If JDK 9/10 ever transform primitives natively into real objects without today's boxing, you could then deprecate the entire package. Paul On Fri, Dec 21, 2012 at 4:47 PM, wrote: > Changeset: 34d14e377743 > Author: briangoetz > Date: 2012-12-21 17:47 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/34d14e377743 > > Renamings and reorganizations, mostly away from .primitive package into desired target locations > > + src/share/classes/java/util/OptionalDouble.java > + src/share/classes/java/util/OptionalInt.java > + src/share/classes/java/util/OptionalLong.java > + src/share/classes/java/util/function/IntMultiFunction.java > + src/share/classes/java/util/stream/IntPipeline.java > + src/share/classes/java/util/stream/IntStream.java > ! src/share/classes/java/util/stream/ReferencePipeline.java > ! src/share/classes/java/util/stream/Stream.java > ! src/share/classes/java/util/stream/StreamShape.java > ! src/share/classes/java/util/stream/op/FindOp.java > - src/share/classes/java/util/stream/primitive/DoubleOptional.java > ! src/share/classes/java/util/stream/primitive/IntFoldOp.java > - src/share/classes/java/util/stream/primitive/IntMultiFunction.java > - src/share/classes/java/util/stream/primitive/IntMutableReducer.java > ! src/share/classes/java/util/stream/primitive/IntNodes.java > - src/share/classes/java/util/stream/primitive/IntOptional.java > - src/share/classes/java/util/stream/primitive/IntPipeline.java > ! src/share/classes/java/util/stream/primitive/IntSortedOp.java > - src/share/classes/java/util/stream/primitive/IntStream.java > - src/share/classes/java/util/stream/primitive/LongOptional.java > ! src/share/classes/java/util/stream/reduce/MutableReducer.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamLinkTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamReuseTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindAnyOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindFirstOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MatchOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntMinMaxTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntMultiMapOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntReduceTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamSpliteratorTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java > > From henry.jen at oracle.com Fri Dec 21 16:17:24 2012 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 21 Dec 2012 16:17:24 -0800 Subject: RFR: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50D4D681.3040009@gmail.com> References: <50D40178.3060604@oracle.com> <50D4A1F0.4090206@gmail.com> <50D4D681.3040009@gmail.com> Message-ID: <739A7241-995B-43B2-BCAF-E0F7E8E92FD6@oracle.com> And deal with serialization is also another concern. As I don't think *ALL* handlers use a different log level to Logger would be that a common case, current implementation should be effective. This patch is a really simple idea, and as Peter and Remi both have pointed out, there is an associated cost of lambda form. What to expect here is a reasonable saving by replace message construction cost with lambda construction cost. The block form is really an attempt to not repeating the code everywhere, but the efficient concern is real, so we should probably just copy&paste instead of use block. The renaming idea is a good one. The original thought is to keep the API arguments in place. Now that Peter proposed, it's definitely looks better and apparently is acceptable to developers. Cheers, Henry On Dec 21, 2012, at 1:37 PM, Peter Levart wrote: > On 12/21/2012 06:52 PM, Peter Levart wrote: >> Hi Henry, again, >> >> To delay constructing message to as late as possible, you could construct a LogRecord with a reference to Supplier and only evaluate the Supplier on the first call to LogRecord.getMessage() and then cache-it. Like the following: >> >> http://dl.dropbox.com/u/101777488/jdk8-tl/LogRecord/webrev/index.html >> > On a second thought, the above might not be a good idea. The message should be materialized before passing the LogRecord to a handler, since some handlers might evaluate message in a special "logging" thread and therefore invoking a user provided Supplier in another thread might have undesirable effects (threading issues)... > > Regards, Peter > >> Also, the "staging" Block call-back in doLog() is a very nice lambda usage, but it comes with a cost of constructing another lambda object for each call to those methods... >> >> Regards, Peter >> >> On 12/21/2012 07:28 AM, Henry Jen wrote: >>> Hi, >>> >>> This patch adds a couple APIs to java.util.logging.Logger so that >>> construction of log messages only occurs when it is actually to be >>> logged by using Supplier instead of String. >>> >>> Since the idea is to avoid unnecessary construction of log messages, >>> thus APIs imply formatting are not provided. Thus all forms of logrb and >>> log with Parameters are not included. >>> >>> log with Throwable are named to be logEx or logpEx to avoid null >>> ambiguous as it seems like it's quite common usage with >>> >>> logger.log(level, null, thrown) >>> >>> Specdiff and webrev can be found at following, >>> >>> >>> http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/specdiff/diff.html >>> http://cr.openjdk.java.net/~henryjen/ccc/8005263.0/webrev/ >>> >>> >>> Cheers, >>> Henry >>> >> > From henry.jen at oracle.com Fri Dec 21 20:50:18 2012 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 21 Dec 2012 20:50:18 -0800 Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message Message-ID: <50D53C0A.6000203@oracle.com> Hi, Update patch with review feedback, - JavaDoc update for benefit and gotcha. - logEx/logpEx is not log/logp with Supplier as last argument. As a matter of fact, all API with Supplier takes it as last argument. - No more doLog(Level, Supplier, Block) helper for performance concerns. Specdiff and webrev can be found at following, http://cr.openjdk.java.net/~henryjen/ccc/8005263.1/specdiff/diff.html http://cr.openjdk.java.net/~henryjen/ccc/8005263.1/webrev/ Cheers, Henry From mthornton at optrak.com Sat Dec 22 00:45:37 2012 From: mthornton at optrak.com (Mark Thornton) Date: Sat, 22 Dec 2012 08:45:37 +0000 Subject: RFR: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50D40178.3060604@oracle.com> References: <50D40178.3060604@oracle.com> Message-ID: <50D57331.2050904@optrak.com> On 21/12/12 06:28, Henry Jen wrote: > Since the idea is to avoid unnecessary construction of log messages, > thus APIs imply formatting are not provided. Thus all forms of logrb and > log with Parameters are not included. Avoiding unnecessary formatting wasn't the only justification for parameters. It also allows the formatting to take place later using the locale of the reader, which isn't necessarily the locale in force at the time the message is logged. Mark Thornton From peter.levart at gmail.com Sat Dec 22 03:13:55 2012 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 22 Dec 2012 12:13:55 +0100 Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50D53C0A.6000203@oracle.com> References: <50D53C0A.6000203@oracle.com> Message-ID: <50D595F3.4070101@gmail.com> Hi Henry, Plain and simple. I just noticed a few spellings: line 670, 696, 863: "Thus is it" -> "Thus it is" - this one has already been written wrong in the original source, so it just multiplied by copy-paste line 688, 743, 854: "Log a in-time" -> "Log an in-time" Regards, Peter On 12/22/2012 05:50 AM, Henry Jen wrote: > Hi, > > Update patch with review feedback, > - JavaDoc update for benefit and gotcha. > - logEx/logpEx is not log/logp with Supplier as last argument. > As a matter of fact, all API with Supplier takes it as last > argument. > - No more doLog(Level, Supplier, Block) helper for > performance concerns. > > Specdiff and webrev can be found at following, > > http://cr.openjdk.java.net/~henryjen/ccc/8005263.1/specdiff/diff.html > http://cr.openjdk.java.net/~henryjen/ccc/8005263.1/webrev/ > > Cheers, > Henry > From peter.levart at gmail.com Sat Dec 22 05:18:22 2012 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 22 Dec 2012 14:18:22 +0100 Subject: RFR: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50D57331.2050904@optrak.com> References: <50D40178.3060604@oracle.com> <50D57331.2050904@optrak.com> Message-ID: <50D5B31E.9000606@gmail.com> On 12/22/2012 09:45 AM, Mark Thornton wrote: > On 21/12/12 06:28, Henry Jen wrote: >> Since the idea is to avoid unnecessary construction of log messages, >> thus APIs imply formatting are not provided. Thus all forms of logrb and >> log with Parameters are not included. > Avoiding unnecessary formatting wasn't the only justification for > parameters. It also allows the formatting to take place later using the > locale of the reader, which isn't necessarily the locale in force at the > time the message is logged. That's true, but for this purpose, i think the messages itself is a key into the resource bundle and it's hard to imagine the need to construct such keys lazily because of performance concerns... Regards, Peter > > Mark Thornton > From marc at petit-huguenin.org Sat Dec 22 09:25:14 2012 From: marc at petit-huguenin.org (Marc Petit-Huguenin) Date: Sat, 22 Dec 2012 09:25:14 -0800 Subject: make images fails Message-ID: <50D5ECFA.5050101@petit-huguenin.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I have this error when building the images, even from a fresh build directory, and I do not know how to fix it: error: bad class file: /home/petithug/lambda/build/linux-x86_64-normal-server-release/images/lib/rt.jar(java/util/stream/IntPipeline$1.class) bad enclosing method attribute for class java.util.stream.IntPipeline$1 Please remove or make sure it appears in the correct subdirectory of the classpath. - -- Marc Petit-Huguenin Email: marc at petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQ1ez5AAoJECnERZXWan7EHu8P/A7fCnz/HtAulqRkt0thaz1m LZOo1jiFlIx0QL+mSE8loC5FPiLZGt5jW3oE5Ues6y4KYGPr++Z+t9qeN6e8aEWn Ot+jpLiDD6/FpweKrg2BD8WAqYc984B6YZby2boc+yVQFwO+sY32h1XBW9Jfrpju kk+Dyt/ZlreITBcmWsIlMSj+H4HIFC6vX83OpLj+GISG/vHUZQIOe8GN2vyC6E9G INuy7KW+2BEv6MY84DaeSICMDlCvXpYnWLTTA7JVEyKhOoBL5K8uHlQ4Hm+2SbPy 5iYfetooac6xZCmqgimxKVkFzoJkfcTJfINm55Wd85n/fA8inaFvtKZbxJA9qvLe tTQvxrbjLPrvMFFnrZNB8rooxo8o8e3AVWW1bKLqXaAMGHqLqlCTtAC7j9J3H3Ln 0qgqxMIdVFoVbrFIjJzcnjISEWm5gg4BaphcgsDtIIVdQqKpchPrysr3E439ym+S gIkwGsGLd6M91RqZGLxpUTJi9g95aWr6uprfPZGayUjKcR2c2fsaXIx+8OESugpA lkTbIUYv85oCxOh1c2ACnsopeMLVUK3H2PBeokRAB6BkcLWaaivP5PZj40Y5/QFS dWWHUjaNFstSy+P8bpSlnPaUN1JsDaaw63+wkVNO7czJUsrFnLrUHjpOKEKDqb/6 KVqBkLQniwdisk6UaDZo =OLjz -----END PGP SIGNATURE----- From brian.goetz at oracle.com Sat Dec 22 09:29:01 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 22 Dec 2012 12:29:01 -0500 Subject: make images fails In-Reply-To: <50D5ECFA.5050101@petit-huguenin.org> References: <50D5ECFA.5050101@petit-huguenin.org> Message-ID: <50D5EDDD.2010308@oracle.com> Yes, Robert has run into something similar, and we're looking into it. It may be a compiler bug, but it definitely gets tickled with "make images" and not when just doing an ordinary "make" (and setting JAVA_HOME to the build/blah/jdk directory.) On 12/22/2012 12:25 PM, Marc Petit-Huguenin wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I have this error when building the images, even from a fresh build directory, > and I do not know how to fix it: > > error: bad class file: > /home/petithug/lambda/build/linux-x86_64-normal-server-release/images/lib/rt.jar(java/util/stream/IntPipeline$1.class) > bad enclosing method attribute for class java.util.stream.IntPipeline$1 > Please remove or make sure it appears in the correct subdirectory of the > classpath. > > - -- > Marc Petit-Huguenin > Email: marc at petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iQIcBAEBCAAGBQJQ1ez5AAoJECnERZXWan7EHu8P/A7fCnz/HtAulqRkt0thaz1m > LZOo1jiFlIx0QL+mSE8loC5FPiLZGt5jW3oE5Ues6y4KYGPr++Z+t9qeN6e8aEWn > Ot+jpLiDD6/FpweKrg2BD8WAqYc984B6YZby2boc+yVQFwO+sY32h1XBW9Jfrpju > kk+Dyt/ZlreITBcmWsIlMSj+H4HIFC6vX83OpLj+GISG/vHUZQIOe8GN2vyC6E9G > INuy7KW+2BEv6MY84DaeSICMDlCvXpYnWLTTA7JVEyKhOoBL5K8uHlQ4Hm+2SbPy > 5iYfetooac6xZCmqgimxKVkFzoJkfcTJfINm55Wd85n/fA8inaFvtKZbxJA9qvLe > tTQvxrbjLPrvMFFnrZNB8rooxo8o8e3AVWW1bKLqXaAMGHqLqlCTtAC7j9J3H3Ln > 0qgqxMIdVFoVbrFIjJzcnjISEWm5gg4BaphcgsDtIIVdQqKpchPrysr3E439ym+S > gIkwGsGLd6M91RqZGLxpUTJi9g95aWr6uprfPZGayUjKcR2c2fsaXIx+8OESugpA > lkTbIUYv85oCxOh1c2ACnsopeMLVUK3H2PBeokRAB6BkcLWaaivP5PZj40Y5/QFS > dWWHUjaNFstSy+P8bpSlnPaUN1JsDaaw63+wkVNO7czJUsrFnLrUHjpOKEKDqb/6 > KVqBkLQniwdisk6UaDZo > =OLjz > -----END PGP SIGNATURE----- > From robert.field at oracle.com Sat Dec 22 11:38:45 2012 From: robert.field at oracle.com (Robert Field) Date: Sat, 22 Dec 2012 11:38:45 -0800 Subject: make images fails In-Reply-To: <50D5EDDD.2010308@oracle.com> References: <50D5ECFA.5050101@petit-huguenin.org> <50D5EDDD.2010308@oracle.com> Message-ID: <50D60C45.1010106@oracle.com> Yes, definitely a compiler bug. The lambda method isn't seen within the scope of the class, because it is synthetic, by the compiler on reading in of the class file, so it appears to the compiler that the enclosing method attribute is referencing a non-existent method. The VM doesn't care about such things, so execution should not be impacted (assuming you can compile without explicitly referencing those classes). -Robert On 12/22/12 09:29, Brian Goetz wrote: > Yes, Robert has run into something similar, and we're looking into it. > It may be a compiler bug, but it definitely gets tickled with "make > images" and not when just doing an ordinary "make" (and setting > JAVA_HOME to the build/blah/jdk directory.) > > On 12/22/2012 12:25 PM, Marc Petit-Huguenin wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> I have this error when building the images, even from a fresh build directory, >> and I do not know how to fix it: >> >> error: bad class file: >> /home/petithug/lambda/build/linux-x86_64-normal-server-release/images/lib/rt.jar(java/util/stream/IntPipeline$1.class) >> bad enclosing method attribute for class java.util.stream.IntPipeline$1 >> Please remove or make sure it appears in the correct subdirectory of the >> classpath. >> >> - -- >> Marc Petit-Huguenin >> Email: marc at petit-huguenin.org >> Blog: http://blog.marc.petit-huguenin.org >> Profile: http://www.linkedin.com/in/petithug >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> >> iQIcBAEBCAAGBQJQ1ez5AAoJECnERZXWan7EHu8P/A7fCnz/HtAulqRkt0thaz1m >> LZOo1jiFlIx0QL+mSE8loC5FPiLZGt5jW3oE5Ues6y4KYGPr++Z+t9qeN6e8aEWn >> Ot+jpLiDD6/FpweKrg2BD8WAqYc984B6YZby2boc+yVQFwO+sY32h1XBW9Jfrpju >> kk+Dyt/ZlreITBcmWsIlMSj+H4HIFC6vX83OpLj+GISG/vHUZQIOe8GN2vyC6E9G >> INuy7KW+2BEv6MY84DaeSICMDlCvXpYnWLTTA7JVEyKhOoBL5K8uHlQ4Hm+2SbPy >> 5iYfetooac6xZCmqgimxKVkFzoJkfcTJfINm55Wd85n/fA8inaFvtKZbxJA9qvLe >> tTQvxrbjLPrvMFFnrZNB8rooxo8o8e3AVWW1bKLqXaAMGHqLqlCTtAC7j9J3H3Ln >> 0qgqxMIdVFoVbrFIjJzcnjISEWm5gg4BaphcgsDtIIVdQqKpchPrysr3E439ym+S >> gIkwGsGLd6M91RqZGLxpUTJi9g95aWr6uprfPZGayUjKcR2c2fsaXIx+8OESugpA >> lkTbIUYv85oCxOh1c2ACnsopeMLVUK3H2PBeokRAB6BkcLWaaivP5PZj40Y5/QFS >> dWWHUjaNFstSy+P8bpSlnPaUN1JsDaaw63+wkVNO7czJUsrFnLrUHjpOKEKDqb/6 >> KVqBkLQniwdisk6UaDZo >> =OLjz >> -----END PGP SIGNATURE----- >> From brian.goetz at oracle.com Sun Dec 23 10:36:41 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 23 Dec 2012 13:36:41 -0500 Subject: RFR: CR#8004561 : Additional Functional Interfaces and Updates In-Reply-To: References: Message-ID: <50D74F39.4090700@oracle.com> Yes, this is a deliberate u-turn that comes as a result of the unexpected interactions with the overloading resolution rules. By having DoubleBlock extending Block, we created problems for overloading. For example, consider this expected-to-be-common overloading in Bunch: Bunch transform(Function transformer) IntBunch transform(IntFunction transformer) There are some conflicting rules in overload selection: - prefer more-specific SAMs to less specific (favors IntFunction) - prefer less boxing/unboxing What we'd like is to choose the former when the "natural" type of transformer is T -> Integer and the latter when the "natural" type is T -> int. But, because the more specific rule has higher priority, we would coerce a T -> Integer into a T -> int (with unboxing) all the time. On 12/20/2012 9:07 PM, Howard Lovatt wrote: > 1. DoubleBlock doesn't extend Block and doesn't have a default > method, similarly int and long > 2. Similarly all the rest like Function aren't extended > > Is this the correct link - it seems to have gone backwards? > > -- Howard. > > > On 21 December 2012 12:41, Mike Duigou wrote: > >> Hello all; >> >> Here are some additional functional interfaces for review. The additions >> fill in holes for primitive types and for two operand "Bi" operations. >> >> http://cr.openjdk.java.net/~mduigou/8004561/0/webrev/ >> >> http://cr.openjdk.java.net/~mduigou/8004561/0/specdiff/java/util/function/package-summary.html >> >> Additionally, this patch contains naming updates on the existing >> functional interfaces following 335 EG review. It does not include the >> interface specializations and default methods previously proposed in >> CR#8004015. That proposal has been withdrawn. It turned out that user >> errors involving unexpected boxing were just too common for the value >> provided. >> >> Mike >> >> > > From brian.goetz at oracle.com Sun Dec 23 10:45:08 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 23 Dec 2012 13:45:08 -0500 Subject: RFR: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50D45601.10501@univ-mlv.fr> References: <50D40178.3060604@oracle.com> <50D42A64.3050804@oracle.com> <50D45601.10501@univ-mlv.fr> Message-ID: <50D75134.7060907@oracle.com> >> Henry - just a quick comment on the class description. I think it would >> be better not to include the sentence "Since 1.8 ..." as it that will >> quickly become a historical note. It would be much better (in my view) >> to just highlight the methods with something like "Several of the >> methods take a Supplier function ..." and make the potential performance >> benefit of using these methods clear. > > You should also add a note saying that the supplier can be specified as > a lambda and in that case, the lambda *must* not capture value of local > variable, otherwise a supplier object will be created each time you log > something. No, don't do this. First of all, just because the performance characteristics of capturing lambdas are one way today on HotSpot compared to non-capturing, does not mean we should burn this into spec. Also, there's no way to enforce it. More importantly, a capturing lambda might still be way better than a String, as in this example: log(DEBUG, () -> "Children of " + name + ": " + getChildrenOf(name)); Collecting getChildren (and turning it into a String) commonly involves something thousands of times as expensive as an object creation. From dmitry.bessonov at oracle.com Sun Dec 23 11:11:29 2012 From: dmitry.bessonov at oracle.com (Dmitry Bessonov) Date: Sun, 23 Dec 2012 23:11:29 +0400 Subject: Expected ISE on forking/linking for sequential()/parallel() methods not always happen Message-ID: <50D75761.6060507@oracle.com> Hello, Expected IllegalStateExceptions is not always thrown when stream (looks like) has been already linked to a child stream. The problem occurs with sequential()/parallel() methods when source is of the same type: Stream s = Arrays.asList(1, 2, 3).parallelStream(); Stream p1 = s.parallel(); Stream p2 = s.parallel(); Stream s1 = s.sequential(); No ISEs thrown. Just as nothing happens in the case of sequential stream: Stream s = Arrays.asList(1, 2, 3).stream(); Stream f1 = s.filter( e -> true ); Stream s1 = s.sequential(); Stream s2 = s.sequential(); Stream s3 = s.sequential(); s, s1, s2, s3 refer to the same instance. The spec for sequential() gives some slight hint on this. Method parallel() has no spec (in b69) at all. I might assume that the verdict - if it's a bug or not depends on how exactly possibly thrown "java.lang.IllegalStateException: Stream is already linked to a child stream" is going to be specified. -Dmitry From brian.goetz at oracle.com Sun Dec 23 12:15:09 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 23 Dec 2012 15:15:09 -0500 Subject: Expected ISE on forking/linking for sequential()/parallel() methods not always happen In-Reply-To: <50D75761.6060507@oracle.com> References: <50D75761.6060507@oracle.com> Message-ID: <50D7664D.6010100@oracle.com> For the implementation, .sequential() on an already-sequential stream and .parallel() on an already-parallel stream is a no-op ("return this"). This is something to call out in the spec: "implementations may..." Thanks, -Brian On 12/23/2012 2:11 PM, Dmitry Bessonov wrote: > Hello, > > Expected IllegalStateExceptions is not always thrown when stream (looks > like) has been already linked to a child stream. > > The problem occurs with sequential()/parallel() methods when source is > of the same type: > > Stream s = Arrays.asList(1, 2, 3).parallelStream(); > Stream p1 = s.parallel(); > Stream p2 = s.parallel(); > Stream s1 = s.sequential(); > > No ISEs thrown. Just as nothing happens in the case of sequential stream: > > Stream s = Arrays.asList(1, 2, 3).stream(); > Stream f1 = s.filter( e -> true ); > Stream s1 = s.sequential(); > Stream s2 = s.sequential(); > Stream s3 = s.sequential(); > > s, s1, s2, s3 refer to the same instance. > The spec for sequential() gives some slight hint on this. > Method parallel() has no spec (in b69) at all. > > I might assume that the verdict - if it's a bug or not depends on how > exactly possibly thrown > "java.lang.IllegalStateException: Stream is already linked to a child > stream" > is going to be specified. > > -Dmitry > From forax at univ-mlv.fr Mon Dec 24 07:55:05 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 24 Dec 2012 16:55:05 +0100 Subject: RFR: CR#8004561 : Additional Functional Interfaces and Updates In-Reply-To: <50D74F39.4090700@oracle.com> References: <50D74F39.4090700@oracle.com> Message-ID: <50D87AD9.5040206@univ-mlv.fr> On 12/23/2012 07:36 PM, Brian Goetz wrote: > Yes, this is a deliberate u-turn that comes as a result of the > unexpected interactions with the overloading resolution rules. maybe it's because the overloading resolution rules are not the right ones ? I've no idea if it's better or not, I'm just thinking loudly. > By having DoubleBlock extending Block, we created problems for > overloading. For example, consider this expected-to-be-common > overloading in Bunch: > > Bunch transform(Function transformer) > IntBunch transform(IntFunction transformer) > > There are some conflicting rules in overload selection: > - prefer more-specific SAMs to less specific (favors IntFunction) > - prefer less boxing/unboxing > > What we'd like is to choose the former when the "natural" type of > transformer is T -> Integer and the latter when the "natural" type is T > -> int. But, because the more specific rule has higher priority, we > would coerce a T -> Integer into a T -> int (with unboxing) all the time. Brian, Why the algorithm that select the most specific SAMs use the return type of the SAM descriptor, the classical algorithm doesn't use the return type. R?mi > > > > > On 12/20/2012 9:07 PM, Howard Lovatt wrote: >> 1. DoubleBlock doesn't extend Block and doesn't have a default >> method, similarly int and long >> 2. Similarly all the rest like Function aren't extended >> >> Is this the correct link - it seems to have gone backwards? >> >> -- Howard. >> >> >> On 21 December 2012 12:41, Mike Duigou wrote: >> >>> Hello all; >>> >>> Here are some additional functional interfaces for review. The additions >>> fill in holes for primitive types and for two operand "Bi" operations. >>> >>> http://cr.openjdk.java.net/~mduigou/8004561/0/webrev/ >>> >>> http://cr.openjdk.java.net/~mduigou/8004561/0/specdiff/java/util/function/package-summary.html >>> >>> Additionally, this patch contains naming updates on the existing >>> functional interfaces following 335 EG review. It does not include the >>> interface specializations and default methods previously proposed in >>> CR#8004015. That proposal has been withdrawn. It turned out that user >>> errors involving unexpected boxing were just too common for the value >>> provided. >>> >>> Mike >>> >>> >> From forax at univ-mlv.fr Mon Dec 24 08:15:34 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 24 Dec 2012 17:15:34 +0100 Subject: RFR: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50D75134.7060907@oracle.com> References: <50D40178.3060604@oracle.com> <50D42A64.3050804@oracle.com> <50D45601.10501@univ-mlv.fr> <50D75134.7060907@oracle.com> Message-ID: <50D87FA6.6070002@univ-mlv.fr> On 12/23/2012 07:45 PM, Brian Goetz wrote: >>> Henry - just a quick comment on the class description. I think it would >>> be better not to include the sentence "Since 1.8 ..." as it that will >>> quickly become a historical note. It would be much better (in my view) >>> to just highlight the methods with something like "Several of the >>> methods take a Supplier function ..." and make the potential >>> performance >>> benefit of using these methods clear. >> >> You should also add a note saying that the supplier can be specified as >> a lambda and in that case, the lambda *must* not capture value of local >> variable, otherwise a supplier object will be created each time you log >> something. > > No, don't do this. > > First of all, just because the performance characteristics of > capturing lambdas are one way today on HotSpot compared to > non-capturing, does not mean we should burn this into spec. It's not related to Hotspot. javac translation uses invokedynamic (by the specification) and the metafactory provided by the JDK uses for non-capturing lambda a ConstantCallSite which is guaranteed by the JSR 292 to be considered as a constant. Hotspot just implements the JSR 292. So this is true for all metafactory implementation that uses a ConstantCallSite as the one provided by the JDK. > Also, there's no way to enforce it. not a lambda problem, but a JSR 292 problem, and it should be enforced by tests, it's JEP 165. > More importantly, a capturing lambda might still be way better than a > String, as in this example: > > log(DEBUG, () -> "Children of " + name + ": " + getChildrenOf(name)); > > Collecting getChildren (and turning it into a String) commonly > involves something thousands of times as expensive as an object creation. Yes, true it depends on the cost of getChildrenOf, my point was to add a sentence saying that using a lambda that capture local variables may impact performance. R?mi From dmitry.bessonov at oracle.com Mon Dec 24 09:00:48 2012 From: dmitry.bessonov at oracle.com (Dmitry Bessonov) Date: Mon, 24 Dec 2012 21:00:48 +0400 Subject: infinite.parallel().sequential().iterator() -> OOM Message-ID: <50D88A40.2020102@oracle.com> Hello, Here's an issue similar to the one reported recently. For example: Streams.repeat("a").parallel().sequential().iterator(); on b69 leads to something like Exception in thread "ForkJoinPool.commonPool-worker-7" Exception in thread "ForkJoinPool.commonPool-worker-3" Exception in thread "ForkJoinPool.commonPool-worker-1" Exception in thread "ForkJoinPool.commonPool-worker-3" java.lang.OutOfMemoryError: Java heap space java.lang.OutOfMemoryError: Java heap space java.lang.OutOfMemoryError: Java heap space -Dmitry From peter.levart at gmail.com Mon Dec 24 09:17:41 2012 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 24 Dec 2012 18:17:41 +0100 Subject: RFR: CR#8004561 : Additional Functional Interfaces and Updates In-Reply-To: <50D87AD9.5040206@univ-mlv.fr> References: <50D74F39.4090700@oracle.com> <50D87AD9.5040206@univ-mlv.fr> Message-ID: <50D88E35.60906@gmail.com> On 12/24/2012 04:55 PM, Remi Forax wrote: > On 12/23/2012 07:36 PM, Brian Goetz wrote: >> Yes, this is a deliberate u-turn that comes as a result of the >> unexpected interactions with the overloading resolution rules. > > maybe it's because the overloading resolution rules are not the right > ones ? > I've no idea if it's better or not, I'm just thinking loudly. > >> By having DoubleBlock extending Block, we created problems for >> overloading. For example, consider this expected-to-be-common >> overloading in Bunch: >> >> Bunch transform(Function transformer) >> IntBunch transform(IntFunction transformer) >> >> There are some conflicting rules in overload selection: >> - prefer more-specific SAMs to less specific (favors IntFunction) >> - prefer less boxing/unboxing >> >> What we'd like is to choose the former when the "natural" type of >> transformer is T -> Integer and the latter when the "natural" type is T >> -> int. But, because the more specific rule has higher priority, we >> would coerce a T -> Integer into a T -> int (with unboxing) all the >> time. > > Brian, Why the algorithm that select the most specific SAMs use the > return type of the SAM descriptor, > the classical algorithm doesn't use the return type. I think Brian was referring to the most specific SAM type. The "classical" algorithm prefers methods with more specific parameter types and SAM type acts as parameter type here. If IntFunction is a subtype of Function then the method with parameter of type IntFunction is selected in preference to Function regardless of lambda's "structural" or "natural" type, provided that lambda conversion is valid for both. If parameter types of two overloaded methods are unrelated (not in a sub-super-type relationship) then the "classical" algorithm barfs, but lambda conversion can use structural properties of unrelated SAM types to select the most appropriate in this case. Regards, Peter > > R?mi > >> >> >> >> >> On 12/20/2012 9:07 PM, Howard Lovatt wrote: >>> 1. DoubleBlock doesn't extend Block and doesn't have a default >>> method, similarly int and long >>> 2. Similarly all the rest like Function aren't extended >>> >>> Is this the correct link - it seems to have gone backwards? >>> >>> -- Howard. >>> >>> >>> On 21 December 2012 12:41, Mike Duigou wrote: >>> >>>> Hello all; >>>> >>>> Here are some additional functional interfaces for review. The >>>> additions >>>> fill in holes for primitive types and for two operand "Bi" operations. >>>> >>>> http://cr.openjdk.java.net/~mduigou/8004561/0/webrev/ >>>> >>>> http://cr.openjdk.java.net/~mduigou/8004561/0/specdiff/java/util/function/package-summary.html >>>> >>>> >>>> Additionally, this patch contains naming updates on the existing >>>> functional interfaces following 335 EG review. It does not include the >>>> interface specializations and default methods previously proposed in >>>> CR#8004015. That proposal has been withdrawn. It turned out that user >>>> errors involving unexpected boxing were just too common for the value >>>> provided. >>>> >>>> Mike >>>> >>>> >>> > From brian.goetz at oracle.com Mon Dec 24 09:31:43 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 24 Dec 2012 12:31:43 -0500 Subject: infinite.parallel().sequential().iterator() -> OOM In-Reply-To: <50D88A40.2020102@oracle.com> References: <50D88A40.2020102@oracle.com> Message-ID: <50D8917F.2030204@oracle.com> Yeah, same issue -- sequential() on a parallel stream is a full barrier. The right answer to this may well be to get rid of sequential(), which is being discussed in the EG. We've found some ways to eliminate its primary motivation. On 12/24/2012 12:00 PM, Dmitry Bessonov wrote: > Hello, > > Here's an issue similar to the one reported recently. For example: > > Streams.repeat("a").parallel().sequential().iterator(); > > on b69 leads to something like > > Exception in thread "ForkJoinPool.commonPool-worker-7" Exception in > thread "ForkJoinPool.commonPool-worker-3" Exception in thread > "ForkJoinPool.commonPool-worker-1" Exception in thread > "ForkJoinPool.commonPool-worker-3" java.lang.OutOfMemoryError: Java heap > space > java.lang.OutOfMemoryError: Java heap space > java.lang.OutOfMemoryError: Java heap space > > > -Dmitry > From dmitry.bessonov at oracle.com Tue Dec 25 06:28:06 2012 From: dmitry.bessonov at oracle.com (Dmitry Bessonov) Date: Tue, 25 Dec 2012 18:28:06 +0400 Subject: Expected ISE on forking/linking for sequential()/parallel() methods not always happen In-Reply-To: <50D7664D.6010100@oracle.com> References: <50D75761.6060507@oracle.com> <50D7664D.6010100@oracle.com> Message-ID: <50D9B7F6.4050006@oracle.com> I think here's another "implementations may..." spec casefound. To throw "java.lang.IllegalStateException: Stream source is already consumed" stream source should truly have been consumed as the following doesn't throw anything: Stream stream = Arrays.asList("a", "b", "c").stream(); stream.into((Stream.Destination) s -> {}); stream.into((Stream.Destination) s -> {}); stream.into((Stream.Destination) s -> {}); -Dmitry On 24.12.2012 0:15, Brian Goetz wrote: > For the implementation, .sequential() on an already-sequential stream > and .parallel() on an already-parallel stream is a no-op ("return this"). > > This is something to call out in the spec: "implementations may..." > > Thanks, > -Brian > > On 12/23/2012 2:11 PM, Dmitry Bessonov wrote: >> Hello, >> >> Expected IllegalStateExceptions is not always thrown when stream (looks >> like) has been already linked to a child stream. >> >> The problem occurs with sequential()/parallel() methods when source is >> of the same type: >> >> Stream s = Arrays.asList(1, 2, 3).parallelStream(); >> Stream p1 = s.parallel(); >> Stream p2 = s.parallel(); >> Stream s1 = s.sequential(); >> >> No ISEs thrown. Just as nothing happens in the case of sequential stream: >> >> Stream s = Arrays.asList(1, 2, 3).stream(); >> Stream f1 = s.filter( e -> true ); >> Stream s1 = s.sequential(); >> Stream s2 = s.sequential(); >> Stream s3 = s.sequential(); >> >> s, s1, s2, s3 refer to the same instance. >> The spec for sequential() gives some slight hint on this. >> Method parallel() has no spec (in b69) at all. >> >> I might assume that the verdict - if it's a bug or not depends on how >> exactly possibly thrown >> "java.lang.IllegalStateException: Stream is already linked to a child >> stream" >> is going to be specified. >> >> -Dmitry >> From howard.lovatt at gmail.com Tue Dec 25 12:25:27 2012 From: howard.lovatt at gmail.com (Howard Lovatt) Date: Wed, 26 Dec 2012 07:25:27 +1100 Subject: RFR: CR#8004561 : Additional Functional Interfaces and Updates In-Reply-To: <50D88E35.60906@gmail.com> References: <50D74F39.4090700@oracle.com> <50D87AD9.5040206@univ-mlv.fr> <50D88E35.60906@gmail.com> Message-ID: <186A83AA-86E2-4BBD-A147-D8C267E5CCB5@gmail.com> The disadvantage of IntFunction not extending Function is that you can no longer provide a function that handles int and Integer and this requirement is also common in my experience. The method I have handled this in my own library is to use a naming convention of prefixing the primitive versions with the type. Therefore I would write Bunch etc. as: interface Function { O call(I i); } interface IntFunction extends Function { default Integer call(I i) { return intCall(i); } int intCall(I i); } DoubleFunction etc. interface Bunch { Bunch transform(Function t); } interface IntBunch extends Bunch { default Bunch transform(Function t) { return intTransform(t); } IntBunch intTransform(IntFunction t); } DoubleBunch etc. The ambiguity goes away because of the naming convention and type hierarchy. -- Howard. Sent from my iPad On 25/12/2012, at 4:17 AM, Peter Levart wrote: > On 12/24/2012 04:55 PM, Remi Forax wrote: >> On 12/23/2012 07:36 PM, Brian Goetz wrote: >>> Yes, this is a deliberate u-turn that comes as a result of the >>> unexpected interactions with the overloading resolution rules. >> >> maybe it's because the overloading resolution rules are not the right >> ones ? >> I've no idea if it's better or not, I'm just thinking loudly. >> >>> By having DoubleBlock extending Block, we created problems for >>> overloading. For example, consider this expected-to-be-common >>> overloading in Bunch: >>> >>> Bunch transform(Function transformer) >>> IntBunch transform(IntFunction transformer) >>> >>> There are some conflicting rules in overload selection: >>> - prefer more-specific SAMs to less specific (favors IntFunction) >>> - prefer less boxing/unboxing >>> >>> What we'd like is to choose the former when the "natural" type of >>> transformer is T -> Integer and the latter when the "natural" type is T >>> -> int. But, because the more specific rule has higher priority, we >>> would coerce a T -> Integer into a T -> int (with unboxing) all the >>> time. >> >> Brian, Why the algorithm that select the most specific SAMs use the >> return type of the SAM descriptor, >> the classical algorithm doesn't use the return type. > I think Brian was referring to the most specific SAM type. The > "classical" algorithm prefers methods with more specific parameter types > and SAM type acts as parameter type here. If IntFunction is a subtype > of Function then the method with parameter of type > IntFunction is selected in preference to Function > regardless of lambda's "structural" or "natural" type, provided that > lambda conversion is valid for both. > > If parameter types of two overloaded methods are unrelated (not in a > sub-super-type relationship) then the "classical" algorithm barfs, but > lambda conversion can use structural properties of unrelated SAM types > to select the most appropriate in this case. > > Regards, Peter >> >> R?mi >> >>> >>> >>> >>> >>> On 12/20/2012 9:07 PM, Howard Lovatt wrote: >>>> 1. DoubleBlock doesn't extend Block and doesn't have a default >>>> method, similarly int and long >>>> 2. Similarly all the rest like Function aren't extended >>>> >>>> Is this the correct link - it seems to have gone backwards? >>>> >>>> -- Howard. >>>> >>>> >>>> On 21 December 2012 12:41, Mike Duigou wrote: >>>> >>>>> Hello all; >>>>> >>>>> Here are some additional functional interfaces for review. The >>>>> additions >>>>> fill in holes for primitive types and for two operand "Bi" operations. >>>>> >>>>> http://cr.openjdk.java.net/~mduigou/8004561/0/webrev/ >>>>> >>>>> http://cr.openjdk.java.net/~mduigou/8004561/0/specdiff/java/util/function/package-summary.html >>>>> >>>>> >>>>> Additionally, this patch contains naming updates on the existing >>>>> functional interfaces following 335 EG review. It does not include the >>>>> interface specializations and default methods previously proposed in >>>>> CR#8004015. That proposal has been withdrawn. It turned out that user >>>>> errors involving unexpected boxing were just too common for the value >>>>> provided. >>>>> >>>>> Mike > > From forax at univ-mlv.fr Tue Dec 25 15:11:18 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 26 Dec 2012 00:11:18 +0100 Subject: RFR: CR#8004561 : Additional Functional Interfaces and Updates In-Reply-To: <50D88E35.60906@gmail.com> References: <50D74F39.4090700@oracle.com> <50D87AD9.5040206@univ-mlv.fr> <50D88E35.60906@gmail.com> Message-ID: <50DA3296.2090502@univ-mlv.fr> On 12/24/2012 06:17 PM, Peter Levart wrote: > On 12/24/2012 04:55 PM, Remi Forax wrote: >> On 12/23/2012 07:36 PM, Brian Goetz wrote: >>> Yes, this is a deliberate u-turn that comes as a result of the >>> unexpected interactions with the overloading resolution rules. >> >> maybe it's because the overloading resolution rules are not the right >> ones ? >> I've no idea if it's better or not, I'm just thinking loudly. >> >>> By having DoubleBlock extending Block, we created problems for >>> overloading. For example, consider this expected-to-be-common >>> overloading in Bunch: >>> >>> Bunch transform(Function transformer) >>> IntBunch transform(IntFunction transformer) >>> >>> There are some conflicting rules in overload selection: >>> - prefer more-specific SAMs to less specific (favors IntFunction) >>> - prefer less boxing/unboxing >>> >>> What we'd like is to choose the former when the "natural" type of >>> transformer is T -> Integer and the latter when the "natural" type is T >>> -> int. But, because the more specific rule has higher priority, we >>> would coerce a T -> Integer into a T -> int (with unboxing) all the >>> time. >> >> Brian, Why the algorithm that select the most specific SAMs use the >> return type of the SAM descriptor, >> the classical algorithm doesn't use the return type. > I think Brian was referring to the most specific SAM type. The > "classical" algorithm prefers methods with more specific parameter > types and SAM type acts as parameter type here. If IntFunction is a > subtype of Function then the method with parameter of type > IntFunction is selected in preference to Function > regardless of lambda's "structural" or "natural" type, provided that > lambda conversion is valid for both. > > If parameter types of two overloaded methods are unrelated (not in a > sub-super-type relationship) then the "classical" algorithm barfs, but > lambda conversion can use structural properties of unrelated SAM types > to select the most appropriate in this case. yes, I know, my question is why the algorithm uses the return type when comparing SAM types structurally ? > > Regards, Peter >> >> R?mi regards, R?mi >> >>> >>> >>> >>> >>> On 12/20/2012 9:07 PM, Howard Lovatt wrote: >>>> 1. DoubleBlock doesn't extend Block and doesn't have a default >>>> method, similarly int and long >>>> 2. Similarly all the rest like Function aren't extended >>>> >>>> Is this the correct link - it seems to have gone backwards? >>>> >>>> -- Howard. >>>> >>>> >>>> On 21 December 2012 12:41, Mike Duigou wrote: >>>> >>>>> Hello all; >>>>> >>>>> Here are some additional functional interfaces for review. The >>>>> additions >>>>> fill in holes for primitive types and for two operand "Bi" >>>>> operations. >>>>> >>>>> http://cr.openjdk.java.net/~mduigou/8004561/0/webrev/ >>>>> >>>>> http://cr.openjdk.java.net/~mduigou/8004561/0/specdiff/java/util/function/package-summary.html >>>>> >>>>> >>>>> Additionally, this patch contains naming updates on the existing >>>>> functional interfaces following 335 EG review. It does not include >>>>> the >>>>> interface specializations and default methods previously proposed in >>>>> CR#8004015. That proposal has been withdrawn. It turned out that user >>>>> errors involving unexpected boxing were just too common for the value >>>>> provided. >>>>> >>>>> Mike >>>>> >>>>> >>>> >> > From denis.debarbieux at inria.fr Wed Dec 26 04:13:43 2012 From: denis.debarbieux at inria.fr (Denis DEBARBIEUX) Date: Wed, 26 Dec 2012 13:13:43 +0100 Subject: Question about type inference. Message-ID: <50DAE9F7.4070003@inria.fr> Hi all, I'm trying to run examples with type inference. The following example fails: public class Main{ / //public static void main(String[] args) {// // System.out.println("start");// // Set> stream = getStream(); // // stream.stream().filter(set -> set.size() == 0).forEach(System.out::println);// // System.out.println("end");// //}// // //private static Set> getStream() {// // Set> stream = new HashSet<>();// // add(stream, Collections.emptyList()); // fail// // // Main.>add(stream, Collections.emptyList()); // OK // // return Collections.unmodifiableSet(stream);// //}// // // //private static void add(Set set, T element) {// // set.add(element);// //}// // } //lambda-8-b69-windows-i586-17_dec_2012/jdk1.8.0/bin/javac test/Main.java// //test\Main.java:34: error: method add in class Main cannot be applied to given types;// // add(stream, Collections.emptyList()); // fail// // ^// // required: Set,T// // found: Set>,List// // reason: inferred type does not conform to lower bound(s)// // inferred: List// // lower bound(s): List// // where T is a type-variable:// // T extends Object declared in method add(Set,T)// //1 error/ Is this supposed to work ? Thanks Denis // -- Denis Debarbieux Engineer at INRIA +33 (0)3.59.35.87.10 Skype: denis.debarbieux From denis.debarbieux at inria.fr Wed Dec 26 05:39:49 2012 From: denis.debarbieux at inria.fr (Denis DEBARBIEUX) Date: Wed, 26 Dec 2012 14:39:49 +0100 Subject: Unexpected variable ... is already defined ... Message-ID: <50DAFE25.8050201@inria.fr> Hi, In the following example, I embed two functions: /event -> event.match(event -> "a".equals(event.label))/ I got an error "variable event is already defined". I am surprise about that. Is-it expected? If yes, can the inner function (that does the test) use the outer parameter event? Denis Bonus question: does a short syntax exist to code f.apply (f is function)./ //public class Main {// // // public static void main(String[] args) {// // System.out.println("start");// //// // // Function test = (event -> "a".equals(event.label));// // // Function matcher = (event -> event.match(test));// //// // getStream().map(event -> event.match(_event -> "a".equals(_event.label))).forEach(System.out::println); // OK// // getStream().map(event -> event.match(event -> "a".equals(event.label))).forEach(System.out::println); // KO// //// // System.out.println("end");// // }// // // private static Stream getStream() {// // List stream = new ArrayList<>();// // stream.add(new Event("a"));// // stream.add(new Event("b"));// // return stream.stream();// // }// // //}// // //class Event {// //// // final String label;// // // public Event(String label) {// // super();// // this.label = label;// // }// //// // MatchEvent match(Function f) {// // // question: short synaxe for apply?// // return new MatchEvent(this, f.apply(this));// // }// // // @Override// // public String toString() {// // return "Event [label=" + label + "]";// // }// //// //// //// //}// // //class MatchEvent {// //// // final Event event;// // final boolean match;// //// // public MatchEvent(Event event, boolean match) {// // super();// // this.event = event;// // this.match = match;// // }// // // @Override// // public String toString() {// // return "MatchEvent [event=" + event + ", match=" + match + "]";// // }// //// //}/ -- Denis Debarbieux Engineer at INRIA +33 (0)3.59.35.87.10 Skype: denis.debarbieux From forax at univ-mlv.fr Wed Dec 26 05:50:57 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 26 Dec 2012 14:50:57 +0100 Subject: Unexpected variable ... is already defined ... In-Reply-To: <50DAFE25.8050201@inria.fr> References: <50DAFE25.8050201@inria.fr> Message-ID: <50DB00C1.80001@univ-mlv.fr> On 12/26/2012 02:39 PM, Denis DEBARBIEUX wrote: > Hi, > > In the following example, I embed two functions: > /event -> event.match(event -> "a".equals(event.label))/ > > I got an error "variable event is already defined". > > I am surprise about that. Is-it expected? Yes, it's surprising but it's what is currently specified. A parameter of a lambda can not hide a parameter/local variable of its enclosing scope. > > If yes, can the inner function (that does the test) use the outer > parameter event? yes, you can capture the value of parameters and local variables if they are effectively final (not assigned more than once). > > Denis > Bonus question: does a short syntax exist to code f.apply (f is function). No. cheers, R?mi > > //public class Main {// > // > // public static void main(String[] args) {// > // System.out.println("start");// > //// > // // Function test = (event -> > "a".equals(event.label));// > // // Function matcher = (event -> > event.match(test));// > //// > // getStream().map(event -> event.match(_event -> > "a".equals(_event.label))).forEach(System.out::println); // OK// > // getStream().map(event -> event.match(event -> > "a".equals(event.label))).forEach(System.out::println); // KO// > //// > // System.out.println("end");// > // }// > // > // private static Stream getStream() {// > // List stream = new ArrayList<>();// > // stream.add(new Event("a"));// > // stream.add(new Event("b"));// > // return stream.stream();// > // }// > // > //}// > // > //class Event {// > //// > // final String label;// > // > // public Event(String label) {// > // super();// > // this.label = label;// > // }// > //// > // MatchEvent match(Function f) {// > // // question: short synaxe for apply?// > // return new MatchEvent(this, f.apply(this));// > // }// > // > // @Override// > // public String toString() {// > // return "Event [label=" + label + "]";// > // }// > //// > //// > //// > //}// > // > //class MatchEvent {// > //// > // final Event event;// > // final boolean match;// > //// > // public MatchEvent(Event event, boolean match) {// > // super();// > // this.event = event;// > // this.match = match;// > // }// > // > // @Override// > // public String toString() {// > // return "MatchEvent [event=" + event + ", match=" + match + "]";// > // }// > //// > //}/ > > From denis.debarbieux at inria.fr Wed Dec 26 06:13:58 2012 From: denis.debarbieux at inria.fr (Denis DEBARBIEUX) Date: Wed, 26 Dec 2012 15:13:58 +0100 Subject: Unexpected variable ... is already defined ... In-Reply-To: <50DB00C1.80001@univ-mlv.fr> References: <50DAFE25.8050201@inria.fr> <50DB00C1.80001@univ-mlv.fr> Message-ID: <50DB0626.2070803@inria.fr> >> If yes, can the inner function (that does the test) use the outer >> parameter event? > yes, you can capture the value of parameters and local variables if they > are effectively final (not assigned more than once). Thanks for your help. How can you set that the value of a parameter is /final/? /getStream().map(//final//event -> event.matchIfA(//_event//-> "a".equals(//_event//.label))).forEach(System.out::println);/ does not compile. According to my tests, they are not final by default. Denis From denis.debarbieux at inria.fr Wed Dec 26 06:23:55 2012 From: denis.debarbieux at inria.fr (Denis DEBARBIEUX) Date: Wed, 26 Dec 2012 15:23:55 +0100 Subject: Stream of infinite number of elements Message-ID: <50DB087B.1000004@inria.fr> Hi all, To implement the interface /Stream/, I have to implement methods like /max, min, sorted/. What is expected by the interface when my stream is infinite? Throw an exception (does the interface provide an InfiniteStreamException?) or implement them as an any time algorithm? Denis -- Denis Debarbieux Engineer at INRIA +33 (0)3.59.35.87.10 Skype: denis.debarbieux From forax at univ-mlv.fr Wed Dec 26 06:55:33 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 26 Dec 2012 15:55:33 +0100 Subject: Unexpected variable ... is already defined ... In-Reply-To: <50DB0626.2070803@inria.fr> References: <50DAFE25.8050201@inria.fr> <50DB00C1.80001@univ-mlv.fr> <50DB0626.2070803@inria.fr> Message-ID: <50DB0FE5.6090003@univ-mlv.fr> On 12/26/2012 03:13 PM, Denis DEBARBIEUX wrote: >>> If yes, can the inner function (that does the test) use the outer >>> parameter event? >> yes, you can capture the value of parameters and local variables if they >> are effectively final (not assigned more than once). > Thanks for your help. > > How can you set that the value of a parameter is /final/? > > /getStream().map(//final//event -> event.matchIfA(//_event//-> > "a".equals(//_event//.label))).forEach(System.out::println);/ > does not compile. parameters or local variables are final if not assigned, you don't have to declare them final anymore, see section 7 of http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html > > According to my tests, they are not final by default. they are not final, they acts as final. > > Denis > R?mi From boaznahum at gmail.com Wed Dec 26 12:08:58 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Wed, 26 Dec 2012 22:08:58 +0200 Subject: Still cant compile on linux Message-ID: Hi. It already was asked, Any one know what the status of this bug ? bad enclosing method attribute for class java.util.stream.IntPipeline$1 Please remove or make sure it appears in the correct subdirectory of the classpath. Do I need to change boot-jdk ? Thanks - I'm really stuck here Boaz From brian.goetz at oracle.com Wed Dec 26 14:16:10 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 26 Dec 2012 22:16:10 +0000 Subject: hg: lambda/lambda/jdk: Rewrite of SpinedBuffer to be simpler and more efficient; Rewrite of IntSpinedBuffer to be general across all primitive types; elminate broken equals() methods in various Node subtypes, and replace with better equality asserters in test framework; eliminate NodeBuilder.replaceAll. Message-ID: <20121226221641.8D3F0473B6@hg.openjdk.java.net> Changeset: 2a5fa7343c2b Author: briangoetz Date: 2012-12-26 15:01 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/2a5fa7343c2b Rewrite of SpinedBuffer to be simpler and more efficient; Rewrite of IntSpinedBuffer to be general across all primitive types; elminate broken equals() methods in various Node subtypes, and replace with better equality asserters in test framework; eliminate NodeBuilder.replaceAll. ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/op/NodeBuilder.java ! src/share/classes/java/util/stream/op/Nodes.java + src/share/classes/java/util/stream/op/PrimitiveSpinedBuffer.java ! src/share/classes/java/util/stream/op/SpinedBuffer.java - src/share/classes/java/util/stream/op/SpinedBufferHelper.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/IntSortedOp.java - src/share/classes/java/util/stream/primitive/IntSpinedBuffer.java ! src/share/classes/java/util/stream/primitive/PrimitiveIterator.java ! src/share/classes/java/util/stream/primitive/PrimitiveNodeBuilder.java ! src/share/classes/java/util/stream/primitive/PrimitiveNodes.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/SpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindAnyOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ForEachOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/GroupByOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeBuilderTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/PrimitiveOpsTests.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SpinedBufferTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UniqOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntMultiMapOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntUniqOpTest.java From brian.goetz at oracle.com Wed Dec 26 14:17:07 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 26 Dec 2012 22:17:07 +0000 Subject: hg: lambda/lambda/jdk: Eliminate Spliterator.getNaturalSplits; rename split() to trySplit. Message-ID: <20121226221718.E2C5D473B7@hg.openjdk.java.net> Changeset: 5f211bc4e034 Author: briangoetz Date: 2012-12-26 17:16 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/5f211bc4e034 Eliminate Spliterator.getNaturalSplits; rename split() to trySplit. ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/Spliterator.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/Streams.java ! src/share/classes/java/util/stream/op/AbstractTask.java ! src/share/classes/java/util/stream/op/NodeUtils.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/op/PrimitiveSpinedBuffer.java ! src/share/classes/java/util/stream/op/SpinedBuffer.java ! src/share/classes/java/util/stream/primitive/IntNodeUtils.java ! src/share/classes/java/util/stream/primitive/PrimitiveNodes.java ! src/share/classes/java/util/stream/primitive/PrimitiveSpliterator.java ! src/share/classes/java/util/stream/primitive/PrimitiveStreams.java ! test-ng/tests/org/openjdk/tests/java/util/stream/SpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SpinedBufferTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntSpliteratorTest.java From brian.goetz at oracle.com Wed Dec 26 14:30:47 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 26 Dec 2012 22:30:47 +0000 Subject: hg: lambda/lambda/jdk: Add implementations of parallelPrefix() in Arrays for object, int, long, and double arrays. Message-ID: <20121226223058.82602473B8@hg.openjdk.java.net> Changeset: 96b2c9471b09 Author: briangoetz Date: 2012-12-26 17:30 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/96b2c9471b09 Add implementations of parallelPrefix() in Arrays for object, int, long, and double arrays. Contributed-by: dl + src/share/classes/java/util/ArrayPrefixHelpers.java ! src/share/classes/java/util/Arrays.java From per at bothner.com Wed Dec 26 14:56:43 2012 From: per at bothner.com (Per Bothner) Date: Wed, 26 Dec 2012 14:56:43 -0800 Subject: another useful default method - Appendable#appendCodePoint Message-ID: <50DB80AB.5000906@bothner.com> Not directly in Lambda's purview, but this seems like it would be a useful addition to Appendable - and another nice example of how default methods are helpful: package java.io; interface Appendable { ... public Appendable appendCodePoint(int c) throws IOException default { if (c >= 0x10000) { append((char) (((c - 0x10000) >> 10) + 0xD800)); c = (c & 0x3FF) + 0xDC00; } append((char) c); return this; } } -- --Per Bothner per at bothner.com http://per.bothner.com/ From henry.jen at oracle.com Wed Dec 26 16:01:09 2012 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 26 Dec 2012 16:01:09 -0800 Subject: Still cant compile on linux In-Reply-To: References: Message-ID: <4CF55F90-099E-4A50-B17B-9AC9DE3D52EF@oracle.com> It is a known issue. For now, just don't do make images, which is the step having problem. Do 'make NEWBUILD=true' instead, and the JDK build is still available to use under $BUILD_OUTPUT/$CONFIGURATION/jdk. Hope that helps. Cheers, Henry On Dec 26, 2012, at 12:08 PM, Boaz Nahum wrote: > Hi. > > It already was asked, Any one know what the status of this bug ? > > bad enclosing method attribute for class java.util.stream.IntPipeline$1 > Please remove or make sure it appears in the correct subdirectory of > the classpath. > > Do I need to change boot-jdk ? > > Thanks - I'm really stuck here > Boaz > From henry.jen at oracle.com Wed Dec 26 16:23:30 2012 From: henry.jen at oracle.com (Henry Jen) Date: Wed, 26 Dec 2012 16:23:30 -0800 Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: References: <50D53C0A.6000203@oracle.com> Message-ID: <50DB9502.4090406@oracle.com> On 12/22/2012 07:30 AM, Jason Mehrens wrote: > The msg argument in most cases is a string literal because it is either > a resource bundle key or a MessageFormat literal. The established best > practice is to convert on the fly construction of messages to use > the MessageFormat syle logging. This current patch is kind of > anti-pattern of that practice. I would think the real win would be to > delay construction of the 'params' argument in the logging framework. > Allowing the callers to write logger.log(level, "{0}", Foo::bar) and > have the call to bar be lazy eval would be the best of both the logging > world and the lambda world. > For messages not just only for developer, they should be localized as you suggested and in such cases, it is possible to achieve the laziness via Object.toString(), less straightforward than using a lambda, but is possible. Cheers, Henry From mcnepp02 at googlemail.com Thu Dec 27 02:58:51 2012 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Thu, 27 Dec 2012 11:58:51 +0100 Subject: another useful default method - Appendable#appendCodePoint In-Reply-To: <50DB80AB.5000906@bothner.com> References: <50DB80AB.5000906@bothner.com> Message-ID: <50DC29EB.7000207@googlemail.com> Luckily, all that low-level stuff has been dealt with in class java.lang.Character, so your default implementation could be re-written as: public Appendable appendCodePoint(int c) throws IOException default { return append(new String(Character.toChars(c)); } From maurizio.cimadamore at oracle.com Thu Dec 27 03:10:49 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 27 Dec 2012 11:10:49 +0000 Subject: Question about type inference. In-Reply-To: <50DAE9F7.4070003@inria.fr> References: <50DAE9F7.4070003@inria.fr> Message-ID: <50DC2CB9.8080502@oracle.com> We are working on improvements that will make code like this to work. Maurizio On 26/12/12 12:13, Denis DEBARBIEUX wrote: > Hi all, > > I'm trying to run examples with type inference. > > The following example fails: > > public class Main{ > / > //public static void main(String[] args) {// > // System.out.println("start");// > // Set> stream = getStream(); // > // stream.stream().filter(set -> set.size() == 0).forEach(System.out::println);// > // System.out.println("end");// > //}// > // > //private static Set> getStream() {// > // Set> stream = new HashSet<>();// > // add(stream, Collections.emptyList()); // fail// > // // Main.>add(stream, Collections.emptyList()); // OK // > // return Collections.unmodifiableSet(stream);// > //}// > // // > //private static void add(Set set, T element) {// > // set.add(element);// > //}// > // > } > > //lambda-8-b69-windows-i586-17_dec_2012/jdk1.8.0/bin/javac test/Main.java// > //test\Main.java:34: error: method add in class Main cannot be applied to given types;// > // add(stream, Collections.emptyList()); // fail// > // ^// > // required: Set,T// > // found: Set>,List// > // reason: inferred type does not conform to lower bound(s)// > // inferred: List// > // lower bound(s): List// > // where T is a type-variable:// > // T extends Object declared in method add(Set,T)// > //1 error/ > > Is this supposed to work ? > > > Thanks > > Denis > > // > From per at bothner.com Thu Dec 27 10:26:50 2012 From: per at bothner.com (Per Bothner) Date: Thu, 27 Dec 2012 10:26:50 -0800 Subject: another useful default method - Appendable#appendCodePoint In-Reply-To: <50DC29EB.7000207@googlemail.com> References: <50DB80AB.5000906@bothner.com> <50DC29EB.7000207@googlemail.com> Message-ID: <50DC92EA.7050904@bothner.com> On 12/27/2012 02:58 AM, Gernot Neppert wrote: > Luckily, all that low-level stuff has been dealt with in class > java.lang.Character, so your default implementation could be re-written as: > > public Appendable appendCodePoint(int c) throws IOException default { > return append(new String(Character.toChars(c)); > } It could be - if you don't care about performance. Allocating a char[] *and* a String for each character doesn't seem winning ... -- --Per Bothner per at bothner.com http://per.bothner.com/ From jason_mehrens at hotmail.com Thu Dec 27 11:22:27 2012 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Thu, 27 Dec 2012 13:22:27 -0600 Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50DB9502.4090406@oracle.com> References: <50D53C0A.6000203@oracle.com>, , <50DB9502.4090406@oracle.com> Message-ID: Henry, Please don't apply this patch. This patch and the suggested workarounds are still an anti-pattern of the logging API. You don't want to encourage this type of on the fly message construction because it can't be localized. Even Netbeans has a code hint to undo this pattern that you are enabling. The problem with this patch is it fails to meet even its own goals when used it in a real world context. The stated goal is to eliminate unnecessary message construction but, in this patch you will pay the cost of message construction when you create a LogRecord. If you configure a system with MemoryHandler to track the events that lead up to a failure you will pay the message cost on every LogRecord that passes through the ring buffer. With this API change, we are performing costly message construction for evicted and unformatted records which is awful. This same kind of worst case behavior happens when the handler levels are higher than the logger level or if a handler is using a filter to track a specific error. I've used combinations of those logging configurations on production applications to track down elusive errors (See bug 6219960). This patch assumes that if a record is loggable by a logger that it will be formatted and that is incorrect. In the 1.4-1.7 logging, message construction cost is delayed until formatting which is as lazy as it gets in the logging world. Take the workaround you suggest bellow. If you apply Object.toString() to any of the arguments, then that cripples what you can do with custom Filter or custom Formatter because you want to be able to access the arguments in their original form and not the string representation. Also, you always want to use the ResouceBundle assigned to the LogRecord from the logger to do the localization. The msg supplier won't know what that is at the time the lambda is created or I would have to recreate code that the logger already does for me every time I want to log something. It would be easier to do what we've done since 1.4 which is use a guard statement to avoid evaluation of the expensive method call. Against this patch if I use a lambda or a guard they will both evaluate the expensive call under the same scenarios. Take the 'DiagnosisMessages::systemHealthStatus' example from the API docs. Seems fine until you realize that someday you might have to read the output of that statement in a log somewhere or you want to create a filter that only shows when the system is unhealthy. So you start to transform that example and realize that you don't want to create a 'systemHealthStatusWithContextMsg' method because it can't be localized during formatting. You don't want to simply perform msg concatenation because that is bad practice and doesn't use lambda. So skip using the lambda APIs because you can use the parameterized logging with a guard statement and that allows you to localize the message and or use the raw parameter data in a Filter to determine which system value has exceed some threshold without resorting to message parsing. Parameters are always more useful than a preformatted string message. Once you arrive here, there is no need for a message parameter to be anything other than a message format pattern or a resource bundle key. Both of those types of messages are string literals so I don't need a Supplier. I think what would be more powerful and fitting patch would be to overload all of the Logger.finest, Logger.finer, Logger.fine, etc. like 'Logger.finer(String msg, Throwable thrown, Supplier... params)' or use a sub-interface of Supplier. As long as the given Supplier.toString() is implemented as: 'return String.valueof(get())' then the existing logging API would format these lazy parameters the same way and would properly delay the construction cost to only at the time of formatting. Filters would be allowed access to the original parameters through the supplier interface and the already established localization in the logging API would still work. The established best practice of not creating on the fly messages would still remain an enduring goal of the logging API. Respectfully, Jason > For messages not just only for developer, they should be localized as > you suggested and in such cases, it is possible to achieve the laziness > via Object.toString(), less straightforward than using a lambda, but is > possible. > > Cheers, > Henry > From brian.goetz at oracle.com Thu Dec 27 12:40:22 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 27 Dec 2012 15:40:22 -0500 Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: References: <50D53C0A.6000203@oracle.com>, , <50DB9502.4090406@oracle.com> Message-ID: <50DCB236.4020709@oracle.com> I think a significant fraction of the community would disagree with you. We ran a survey where we collected suggestions for lambdafying API methods, and this one came in top of the list. There is a significant fraction of the developer community that uses the logging API and doesn't care at all about localization, but does care about logging performance. One doesn't have to look very far to see that it is common practice to surround logging calls with if (logger.isLogging(level)) logger.log(level, msgExpr) to work around the eager evaluation. And such a practice is brittle, because it's easy to forget to do it in one place, and lose the benefit. Now, your answer might be "force all users to use message catalogs." But that's pretty mean. A lot of users really, really don't want to use message catalogs. They want to do: logger.log(level, () -> String.format(...)); You're basically saying we should force-feed those users some message-catalog vegetables, because it's good for them. > Henry, > Please don't apply this patch. This patch and the suggested workarounds are still an anti-pattern of the logging API. You don't want to encourage this type of on the fly message construction because it can't be localized. Even Netbeans has a code hint to undo this pattern that you are enabling. The problem with this patch is it fails to meet even its own goals when used it in a real world context. The stated goal is to eliminate unnecessary message construction but, in this patch you will pay the cost of message construction when you create a LogRecord. If you configure a system with MemoryHandler to track the events that lead up to a failure you will pay the message cost on every LogRecord that passes through the ring buffer. With this API change, we are performing costly message construction for evicted and unformatted records which is awful. This same kind of worst case behavior happens when the handler levels are higher than the logger level or if a handler is ! using a filter to track a specific error. I've used combinations of those logging configurations on production applications to track down elusive errors (See bug 6219960). This patch assumes that if a record is loggable by a logger that it will be formatted and that is incorrect. In the 1.4-1.7 logging, message construction cost is delayed until formatting which is as lazy as it gets in the logging world. Take the workaround you suggest bellow. If you apply Object.toString() to any of the arguments, then that cripples what you can do with custom Filter or custom Formatter because you want to be able to access the arguments in their original form and not the string representation. Also, you always want to use the ResouceBundle assigned to the LogRecord from the logger to do the localization. The msg supplier won't know what that is at the time the lambda is created or I would have to recreate code that the logger already does for me every time I want to log something. It would! be easie r to do what we've done since 1.4 which is use a guard statement to avoid evaluation of the expensive method call. Against this patch if I use a lambda or a guard they will both evaluate the expensive call under the same scenarios. Take the 'DiagnosisMessages::systemHealthStatus' example from the API docs. Seems fine until you realize that someday you might have to read the output of that statement in a log somewhere or you want to create a filter that only shows when the system is unhealthy. So you start to transform that example and realize that you don't want to create a 'systemHealthStatusWithContextMsg' method because it can't be localized during formatting. You don't want to simply perform msg concatenation because that is bad practice and doesn't use lambda. So skip using the lambda APIs because you can use the parameterized logging with a guard statement and that allows you to localize the message and or use the raw parameter data in a Filter to determine which ! system va lue has exceed some threshold without resorting to message parsing. Parameters are always more useful than a preformatted string message. Once you arrive here, there is no need for a message parameter to be anything other than a message format pattern or a resource bundle key. Both of those types of messages are string literals so I don't need a Supplier. I think what would be more powerful and fitting patch would be to overload all of the Logger.finest, Logger.finer, Logger.fine, etc. like 'Logger.finer(String msg, Throwable thrown, Supplier... params)' or use a sub-interface of Supplier. As long as the given Supplier.toString() is implemented as: 'return String.valueof(get())' then the existing logging API would format these lazy parameters the same way and would properly delay the construction cost to only at the time of formatting. Filters would be allowed access to the original parameters through the supplier interface and the already established localization in th! e logging API would still work. The established best practice of not creating on the fly messages would still remain an enduring goal of the logging API. Respectfully, Jason > >> For messages not just only for developer, they should be localized as >> you suggested and in such cases, it is possible to achieve the laziness >> via Object.toString(), less straightforward than using a lambda, but is >> possible. >> >> Cheers, >> Henry >> > > > > > > From brian.goetz at oracle.com Thu Dec 27 14:59:19 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 27 Dec 2012 22:59:19 +0000 Subject: hg: lambda/lambda/jdk: Merge FindFirstTask and FindAnyTask Message-ID: <20121227225942.4D9F4473E7@hg.openjdk.java.net> Changeset: 77266b843351 Author: briangoetz Date: 2012-12-27 17:59 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/77266b843351 Merge FindFirstTask and FindAnyTask ! src/share/classes/java/util/stream/op/FindOp.java From brian.goetz at oracle.com Thu Dec 27 15:35:05 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Thu, 27 Dec 2012 23:35:05 +0000 Subject: hg: lambda/lambda/jdk: Move PrimitiveSpinedBuffer into primitive package Message-ID: <20121227233517.87E5F473EF@hg.openjdk.java.net> Changeset: 51b919152407 Author: briangoetz Date: 2012-12-27 18:35 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/51b919152407 Move PrimitiveSpinedBuffer into primitive package - src/share/classes/java/util/stream/op/PrimitiveSpinedBuffer.java ! src/share/classes/java/util/stream/primitive/IntNodes.java + src/share/classes/java/util/stream/primitive/PrimitiveSpinedBuffer.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/PrimitiveOpsTests.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SpinedBufferTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestDataProvider.java From venkats at agiledeveloper.com Thu Dec 27 15:40:11 2012 From: venkats at agiledeveloper.com (Venkat Subramaniam) Date: Thu, 27 Dec 2012 16:40:11 -0700 Subject: Return type of trySplit of Spliterator Message-ID: <56FECCD3-04E4-48BC-B096-9ABABEA653A3@agiledeveloper.com> Hi I like the change of the method name from split to trySplit. Wonder if it would be better for the return type to be Optional> instead of Spliterator? Thanks, Venkat From jason_mehrens at hotmail.com Thu Dec 27 16:16:52 2012 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Thu, 27 Dec 2012 18:16:52 -0600 Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50DCB236.4020709@oracle.com> References: <50D53C0A.6000203@oracle.com>, , , , <50DB9502.4090406@oracle.com>, , <50DCB236.4020709@oracle.com> Message-ID: Brian, It's on my list too for lambdafying I just disagree with current implementation. I understand and agree that having to create a guard should not be required. It's awful to have to do. The point is that patch is still way too eager because you don't want to evaluate a message until the LogRecord arrives at a formatter inside of a handler. I don't want force anyone to use catalogs. I want to force everyone to use message parameterized logging (with or without a catalog) because it is powerful, lazy, and doesn't taste like a vegetable. If your concern is sugary sweets then, add overloaded methods that make message parameterized logging easy for the caller. If patch was rewritten like I proposed, it would be as terse as your example bellow. The difference is it would actually be lazy and would be useful when you need to create a custom filter to find some ghost in a production machine. Relevant or not, my patch would also enable lambdas and message catalogs. That is something that will never happen under the current patch. Jason > I think a significant fraction of the community would disagree with you. > We ran a survey where we collected suggestions for lambdafying API > methods, and this one came in top of the list. > There is a significant fraction of the developer community that uses the > logging API and doesn't care at all about localization, but does care > about logging performance. One doesn't have to look very far to see > that it is common practice to surround logging calls with > > if (logger.isLogging(level)) > logger.log(level, msgExpr) > > to work around the eager evaluation. And such a practice is brittle, > because it's easy to forget to do it in one place, and lose the benefit. > Now, your answer might be "force all users to use message catalogs." > But that's pretty mean. A lot of users really, really don't want to use > message catalogs. They want to do: > > logger.log(level, () -> String.format(...)); > > You're basically saying we should force-feed those users some > message-catalog vegetables, because it's good for them. From peter.levart at gmail.com Thu Dec 27 16:42:21 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 28 Dec 2012 01:42:21 +0100 Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50DB9502.4090406@oracle.com> References: <50D53C0A.6000203@oracle.com> <50DB9502.4090406@oracle.com> Message-ID: <50DCEAED.1040006@gmail.com> What about the following API: public class LogRecordFactory { private final Level level; public LogRecordFactory(Level level) { this.level = level; } public LogRecord create(String msg) { return new LogRecord(level, msg); } public LogRecord create(String msg, Object... parameters) { LogRecord lr = create(msg); lr.setParameters(parameters); return lr; } // ...etc... } and then in the Logger... public void log(Level level, Function logRecordProducer) { if (level.intValue() < levelValue || levelValue == offValue) { return; } LogRecord lr = logRecordProducer.apply(new LogRecordFactory(level)); doLog(lr); } which would be used as: logger.log(Level.INFO, lrp -> lrp.create("Status is: %s", getStatus())); Regards, Peter On 12/27/2012 01:23 AM, Henry Jen wrote: > On 12/22/2012 07:30 AM, Jason Mehrens wrote: >> The msg argument in most cases is a string literal because it is either >> a resource bundle key or a MessageFormat literal. The established best >> practice is to convert on the fly construction of messages to use >> the MessageFormat syle logging. This current patch is kind of >> anti-pattern of that practice. I would think the real win would be to >> delay construction of the 'params' argument in the logging framework. >> Allowing the callers to write logger.log(level, "{0}", Foo::bar) and >> have the call to bar be lazy eval would be the best of both the logging >> world and the lambda world. >> > For messages not just only for developer, they should be localized as > you suggested and in such cases, it is possible to achieve the laziness > via Object.toString(), less straightforward than using a lambda, but is > possible. > > Cheers, > Henry > From peter.levart at gmail.com Thu Dec 27 16:55:52 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 28 Dec 2012 01:55:52 +0100 Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50DCEAED.1040006@gmail.com> References: <50D53C0A.6000203@oracle.com> <50DB9502.4090406@oracle.com> <50DCEAED.1040006@gmail.com> Message-ID: <50DCEE18.5070907@gmail.com> And to save creation of a helper object, LogRecordFactory could be an interface implemented by LogRecord... Peter On 12/28/2012 01:42 AM, Peter Levart wrote: > What about the following API: > > public class LogRecordFactory { > > private final Level level; > > public LogRecordFactory(Level level) { > this.level = level; > } > > public LogRecord create(String msg) { > return new LogRecord(level, msg); > } > > public LogRecord create(String msg, Object... parameters) { > LogRecord lr = create(msg); > lr.setParameters(parameters); > return lr; > } > > // ...etc... > } > > > and then in the Logger... > > public void log(Level level, Function > logRecordProducer) { > if (level.intValue() < levelValue || levelValue == offValue) { > return; > } > LogRecord lr = logRecordProducer.apply(new > LogRecordFactory(level)); > doLog(lr); > } > > > which would be used as: > > logger.log(Level.INFO, lrp -> lrp.create("Status is: %s", > getStatus())); > > > Regards, Peter > > > On 12/27/2012 01:23 AM, Henry Jen wrote: >> On 12/22/2012 07:30 AM, Jason Mehrens wrote: >>> The msg argument in most cases is a string literal because it is either >>> a resource bundle key or a MessageFormat literal. The established best >>> practice is to convert on the fly construction of messages to use >>> the MessageFormat syle logging. This current patch is kind of >>> anti-pattern of that practice. I would think the real win would be to >>> delay construction of the 'params' argument in the logging framework. >>> Allowing the callers to write logger.log(level, "{0}", Foo::bar) and >>> have the call to bar be lazy eval would be the best of both the logging >>> world and the lambda world. >> For messages not just only for developer, they should be localized as >> you suggested and in such cases, it is possible to achieve the laziness >> via Object.toString(), less straightforward than using a lambda, but is >> possible. >> >> Cheers, >> Henry >> > From henry.jen at oracle.com Thu Dec 27 18:24:17 2012 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 27 Dec 2012 18:24:17 -0800 Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: References: <50D53C0A.6000203@oracle.com>, , , , <50DB9502.4090406@oracle.com>, , <50DCB236.4020709@oracle.com> Message-ID: As stated in the beginning of the review thread, the reason we don't have Supplier version for other API is that a formatter is involved and can achieve same laziness easily. The key is MessageFormatter can take arguments, which will be used to generate the output. As there is no directly support for Supplier, a possible solution is to have a wrapper class take a Supplier lambda, class Collector { final Supplier supplier; Collector(Supplier supplier) { this.supplier = supplier; } T collect() { return supplier.get(); } @Override String toString() { return supplier.get().toString(); } } It's not entirely beautiful, but is a general solution for applying supplier for MessageFormat. As the handler issue, I would argue that the logger would set to the lowest number required to be logged, i.e, at least one handler will format the message, thus the timing is not an real issue given the other caching/serialization concern discussed. Hope that helps, let me know if I missed something. Cheers, Henry On Dec 27, 2012, at 4:16 PM, Jason Mehrens wrote: > Brian, > > It's on my list too for lambdafying I just disagree with current implementation. I understand and agree that having to create a guard should not be required. It's awful to have to do. The point is that patch is still way too eager because you don't want to evaluate a message until the LogRecord arrives at a formatter inside of a handler. I don't want force anyone to use catalogs. I want to force everyone to use message parameterized logging (with or without a catalog) because it is powerful, lazy, and doesn't taste like a vegetable. If your concern is sugary sweets then, add overloaded methods that make message parameterized logging easy for the caller. If patch was rewritten like I proposed, it would be as terse as your example bellow. The difference is it would actually be lazy and would be useful when you need to create a custom filter to find some ghost in a production machine. Relevant or not, my patch would also enable lambdas and message catalogs. That is something that will never happen under the current patch. > > Jason > > > I think a significant fraction of the community would disagree with you. > > We ran a survey where we collected suggestions for lambdafying API > > methods, and this one came in top of the list. > > There is a significant fraction of the developer community that uses the > > logging API and doesn't care at all about localization, but does care > > about logging performance. One doesn't have to look very far to see > > that it is common practice to surround logging calls with > > > > if (logger.isLogging(level)) > > logger.log(level, msgExpr) > > > > to work around the eager evaluation. And such a practice is brittle, > > because it's easy to forget to do it in one place, and lose the benefit. > > Now, your answer might be "force all users to use message catalogs." > > But that's pretty mean. A lot of users really, really don't want to use > > message catalogs. They want to do: > > > > logger.log(level, () -> String.format(...)); > > > > You're basically saying we should force-feed those users some > > message-catalog vegetables, because it's good for them. > > From paul.sandoz at oracle.com Fri Dec 28 02:19:30 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 28 Dec 2012 10:19:30 +0000 Subject: hg: lambda/lambda/jdk: Refer to primitive type of primitive spined buffer in the abstract Message-ID: <20121228102043.37A1E4741A@hg.openjdk.java.net> Changeset: 220c5c7428d8 Author: psandoz Date: 2012-12-28 11:18 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/220c5c7428d8 Refer to primitive type of primitive spined buffer in the abstract iterator and spliterator implementations. ! src/share/classes/java/util/stream/op/SpinedBuffer.java ! src/share/classes/java/util/stream/primitive/PrimitiveSpinedBuffer.java From paul.sandoz at oracle.com Fri Dec 28 04:30:13 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 28 Dec 2012 12:30:13 +0000 Subject: hg: lambda/lambda/jdk: - Reduce NodeBuilder to a specialization of Sink Message-ID: <20121228123036.DE1954741E@hg.openjdk.java.net> Changeset: 92254c54c12e Author: psandoz Date: 2012-12-28 13:29 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/92254c54c12e - Reduce NodeBuilder to a specialization of Sink - Clean up some ToArrayOp tests - Fix compiler warnings when compiling tests ! src/share/classes/java/util/stream/op/Node.java ! src/share/classes/java/util/stream/op/NodeBuilder.java ! src/share/classes/java/util/stream/primitive/PrimitiveNodeBuilder.java ! test-ng/tests/org/openjdk/tests/java/lang/invoke/SerializedLambdaTest.java ! test-ng/tests/org/openjdk/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestData.java ! test-ng/tests/org/openjdk/tests/java/util/stream/TabulatorsTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FlagDeclaringOp.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeBuilderTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SequentialOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java From forax at univ-mlv.fr Fri Dec 28 06:17:56 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 28 Dec 2012 15:17:56 +0100 Subject: another useful default method - Appendable#appendCodePoint In-Reply-To: <50DB80AB.5000906@bothner.com> References: <50DB80AB.5000906@bothner.com> Message-ID: <50DDAA14.9050405@univ-mlv.fr> On 12/26/2012 11:56 PM, Per Bothner wrote: > Not directly in Lambda's purview, but this seems like it would be > a useful addition to Appendable - and another nice example of how > default methods are helpful: > > package java.io; > interface Appendable { > ... > public Appendable appendCodePoint(int c) throws IOException default { > if (c >= 0x10000) { > append((char) (((c - 0x10000) >> 10) + 0xD800)); > c = (c & 0x3FF) + 0xDC00; > } > append((char) c); > return this; > } > } yes, good idea, playing with code points in Java is not always a pleasure. BTW, default is now a modifier so it should be declared in front of the method, not at the end. R?mi From jason_mehrens at hotmail.com Fri Dec 28 07:15:45 2012 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 28 Dec 2012 09:15:45 -0600 Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: References: <50D53C0A.6000203@oracle.com>, , , , <50DB9502.4090406@oracle.com>, , <50DCB236.4020709@oracle.com>, , Message-ID: Henry, It is beautiful if that code lives only inside of the logger and the caller is unaware of its existence. Same is true for writing a guard statement. The formatter can not always achieve the same laziness. If I converted your example in the API docs to be passed in the params argument I would have to evaluate it to a string before the logger call or create a supplier that overrides toString to return DiagnosisMessages.systemHealthStatus(). We are forcing caller to create the ugly code which the exact opposite of what you are trying to do with this patch. As soon as you use a MemoryHandler or install a Handler filter the levels will be the lowest number required. The problem is you end up throwing out or filtering out volumes of LogRecords that are never formatted. This is common when you are hunting for a specific error and what to see the last X number of messages that led up to the error. That was the technique used to reopen bug id 6840067. If I created a working proof of concept would that change anything or is this patch a done deal? Jason > Subject: Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for message > From: henry.jen at oracle.com > Date: Thu, 27 Dec 2012 18:24:17 -0800 > CC: brian.goetz at oracle.com; lambda-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > To: jason_mehrens at hotmail.com > > As stated in the beginning of the review thread, the reason we don't have Supplier version for other API is that a formatter is involved and can achieve same laziness easily. > > The key is MessageFormatter can take arguments, which will be used to generate the output. As there is no directly support for Supplier, a possible solution is to have a wrapper class take a Supplier lambda, > > class Collector { > final Supplier supplier; > > Collector(Supplier supplier) { > this.supplier = supplier; > } > > T collect() { > return supplier.get(); > } > > @Override > String toString() { > return supplier.get().toString(); > } > } > > It's not entirely beautiful, but is a general solution for applying supplier for MessageFormat. > > As the handler issue, I would argue that the logger would set to the lowest number required to be logged, i.e, at least one handler will format the message, thus the timing is not an real issue given the other caching/serialization concern discussed. > > Hope that helps, let me know if I missed something. > > Cheers, > Henry > > > On Dec 27, 2012, at 4:16 PM, Jason Mehrens wrote: > >> Brian, >> >> It's on my list too for lambdafying I just disagree with current implementation. I understand and agree that having to create a guard should not be required. It's awful to have to do. The point is that patch is still way too eager because you don't want to evaluate a message until the LogRecord arrives at a formatter inside of a handler. I don't want force anyone to use catalogs. I want to force everyone to use message parameterized logging (with or without a catalog) because it is powerful, lazy, and doesn't taste like a vegetable. If your concern is sugary sweets then, add overloaded methods that make message parameterized logging easy for the caller. If patch was rewritten like I proposed, it would be as terse as your example bellow. The difference is it would actually be lazy and would be useful when you need to create a custom filter to find some ghost in a production machine. Relevant or not, my patch would also enable lambdas and message catalogs. That is something that will never happen under the current patch. >> >> Jason >> >>> I think a significant fraction of the community would disagree with you. >>> We ran a survey where we collected suggestions for lambdafying API >>> methods, and this one came in top of the list. >>> There is a significant fraction of the developer community that uses the >>> logging API and doesn't care at all about localization, but does care >>> about logging performance. One doesn't have to look very far to see >>> that it is common practice to surround logging calls with >>> >>> if (logger.isLogging(level)) >>> logger.log(level, msgExpr) >>> >>> to work around the eager evaluation. And such a practice is brittle, >>> because it's easy to forget to do it in one place, and lose the benefit. >>> Now, your answer might be "force all users to use message catalogs." >>> But that's pretty mean. A lot of users really, really don't want to use >>> message catalogs. They want to do: >>> >>> logger.log(level, () -> String.format(...)); >>> >>> You're basically saying we should force-feed those users some >>> message-catalog vegetables, because it's good for them. >> >> > From paul.sandoz at oracle.com Fri Dec 28 07:53:26 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 28 Dec 2012 16:53:26 +0100 Subject: Expected ISE on forking/linking for sequential()/parallel() methods not always happen In-Reply-To: <50D9B7F6.4050006@oracle.com> References: <50D75761.6060507@oracle.com> <50D7664D.6010100@oracle.com> <50D9B7F6.4050006@oracle.com> Message-ID: <9894B0E5-4C3E-49B2-92F9-14BD30C8D33F@oracle.com> On Dec 25, 2012, at 3:28 PM, Dmitry Bessonov wrote: > I think here's another "implementations may..." spec casefound. > > To throw "java.lang.IllegalStateException: Stream source is already > consumed" stream source should truly have been consumed as the following > doesn't throw anything: > > Stream stream = Arrays.asList("a", "b", "c").stream(); > stream.into((Stream.Destination) s -> {}); > stream.into((Stream.Destination) s -> {}); > stream.into((Stream.Destination) s -> {}); > That's because the destination does nothing with the Stream passed to it. The EG is currently discussing how to remove/replace Stream.into. The example you present is a good one of the issues with that method. Paul. From paul.sandoz at oracle.com Fri Dec 28 08:14:12 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 28 Dec 2012 17:14:12 +0100 Subject: Stream of infinite number of elements In-Reply-To: <50DB087B.1000004@inria.fr> References: <50DB087B.1000004@inria.fr> Message-ID: On Dec 26, 2012, at 3:23 PM, Denis DEBARBIEUX wrote: > Hi all, > > To implement the interface /Stream/, I have to implement methods like > /max, min, sorted/. > > What is expected by the interface when my stream is infinite? Undetermined behaviour, unless those terminal operations are prefixed with an intermediate limit operation. The first two might never return and the latter one will most likely throw an OOE. > Throw an > exception (does the interface provide an InfiniteStreamException?) or > implement them as an any time algorithm? > We are considering a cancel or while operation that on say a met temporal condition will ensure no more elements are available, thus non-short-circuit terminal operations should terminate under such conditions. Originally we tried to detect cases when an infinite stream was hooked up to something that would be known to not terminate but we cannot capture all such cases so rather than partially supporting this we decided to go for the "developer beware" option. Paul. From brian.goetz at oracle.com Fri Dec 28 09:00:28 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 28 Dec 2012 17:00:28 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20121228170210.14C3E47422@hg.openjdk.java.net> Changeset: f09417f7d7b9 Author: briangoetz Date: 2012-12-28 11:59 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/f09417f7d7b9 Temporary workaround for compiler 'enclosing method attribute' bug ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/ReferencePipeline.java Changeset: d87fe30d975f Author: briangoetz Date: 2012-12-28 12:00 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d87fe30d975f Merge From brian.goetz at oracle.com Fri Dec 28 10:25:43 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 28 Dec 2012 18:25:43 +0000 Subject: hg: lambda/lambda/jdk: Add BitSet.stream() Message-ID: <20121228182604.270A04742C@hg.openjdk.java.net> Changeset: 606aa9a80b6d Author: briangoetz Date: 2012-12-28 13:25 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/606aa9a80b6d Add BitSet.stream() ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/BitSet.java ! src/share/classes/java/util/stream/reduce/Reducers.java + test-ng/tests/org/openjdk/tests/java/util/BitsetStreamTest.java From brian.goetz at oracle.com Fri Dec 28 10:43:05 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 28 Dec 2012 18:43:05 +0000 Subject: hg: lambda/lambda/jdk: Migrate CharSequence.{chars, codePoints} to be IntStream instead of Stream Message-ID: <20121228184323.C7C414742E@hg.openjdk.java.net> Changeset: df8f518a7674 Author: briangoetz Date: 2012-12-28 13:43 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/df8f518a7674 Migrate CharSequence.{chars,codePoints} to be IntStream instead of Stream ! src/share/classes/java/lang/CharSequence.java ! test-ng/tests/org/openjdk/tests/java/lang/CharSequenceStreamTest.java From forax at univ-mlv.fr Fri Dec 28 10:43:26 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 28 Dec 2012 19:43:26 +0100 Subject: hg: lambda/lambda/jdk: Add BitSet.stream() In-Reply-To: <20121228182604.270A04742C@hg.openjdk.java.net> References: <20121228182604.270A04742C@hg.openjdk.java.net> Message-ID: <50DDE84E.7020501@univ-mlv.fr> On 12/28/2012 07:25 PM, brian.goetz at oracle.com wrote: > Changeset: 606aa9a80b6d > Author: briangoetz > Date: 2012-12-28 13:25 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/606aa9a80b6d > > Add BitSet.stream() > > ! src/share/classes/java/util/Arrays.java > ! src/share/classes/java/util/BitSet.java > ! src/share/classes/java/util/stream/reduce/Reducers.java > + test-ng/tests/org/openjdk/tests/java/util/BitsetStreamTest.java > > There is an easier implementation of BitSetIterator because nextSetBit has no side effect. class BitSetIterator implements PrimitiveIterator.OfInt { private int next = nextSetBit(0); @Override public boolean hasNext() { return next != -1; } @Override public int nextInt() { int index = next; if (index == -1) { throw new NoSuchElementException(); } next = nextSetBit(index + 1); return index; } } cheers, R?mi From brian.goetz at oracle.com Fri Dec 28 11:07:58 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 28 Dec 2012 14:07:58 -0500 Subject: hg: lambda/lambda/jdk: Add BitSet.stream() In-Reply-To: <50DDE84E.7020501@univ-mlv.fr> References: <20121228182604.270A04742C@hg.openjdk.java.net> <50DDE84E.7020501@univ-mlv.fr> Message-ID: <50DDEE0E.5060801@oracle.com> True. The original was based on one where we wanted to deferred binding to the state of the BitSet until the user actually wanted data. Now we accomplish that through the indirection () -> spliterator, so we can back that out. On 12/28/2012 1:43 PM, Remi Forax wrote: > On 12/28/2012 07:25 PM, brian.goetz at oracle.com wrote: >> Changeset: 606aa9a80b6d >> Author: briangoetz >> Date: 2012-12-28 13:25 -0500 >> URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/606aa9a80b6d >> >> Add BitSet.stream() >> >> ! src/share/classes/java/util/Arrays.java >> ! src/share/classes/java/util/BitSet.java >> ! src/share/classes/java/util/stream/reduce/Reducers.java >> + test-ng/tests/org/openjdk/tests/java/util/BitsetStreamTest.java >> >> > > There is an easier implementation of BitSetIterator because nextSetBit > has no side effect. > > class BitSetIterator implements PrimitiveIterator.OfInt { > private int next = nextSetBit(0); > > @Override > public boolean hasNext() { > return next != -1; > } > > @Override > public int nextInt() { > int index = next; > if (index == -1) { > throw new NoSuchElementException(); > } > next = nextSetBit(index + 1); > return index; > } > } > > cheers, > R?mi > > From brian.goetz at oracle.com Fri Dec 28 11:10:25 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 28 Dec 2012 19:10:25 +0000 Subject: hg: lambda/lambda/jdk: Updated BitSet.stream Message-ID: <20121228191045.E923D47431@hg.openjdk.java.net> Changeset: 3232ade9ec5e Author: briangoetz Date: 2012-12-28 14:10 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3232ade9ec5e Updated BitSet.stream ! src/share/classes/java/util/BitSet.java From robert.field at oracle.com Fri Dec 28 11:19:09 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 28 Dec 2012 19:19:09 +0000 Subject: hg: lambda/lambda/langtools: Serialized lambda: test all incoming parameters. Fixes SerializedLambdaTest. Message-ID: <20121228191917.9065647432@hg.openjdk.java.net> Changeset: 920d3226b48b Author: rfield Date: 2012-12-28 11:18 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/920d3226b48b Serialized lambda: test all incoming parameters. Fixes SerializedLambdaTest. ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java From brian.goetz at oracle.com Fri Dec 28 11:36:34 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 28 Dec 2012 14:36:34 -0500 Subject: make images fails In-Reply-To: <50D60C45.1010106@oracle.com> References: <50D5ECFA.5050101@petit-huguenin.org> <50D5EDDD.2010308@oracle.com> <50D60C45.1010106@oracle.com> Message-ID: <50DDF4C2.5050703@oracle.com> I've pushed a workaround that hopefully doesn't tickle this bug, while we're waiting for a fix. On 12/22/2012 2:38 PM, Robert Field wrote: > Yes, definitely a compiler bug. The lambda method isn't seen within the > scope of the class, because it is synthetic, by the compiler on reading > in of the class file, so it appears to the compiler that the enclosing > method attribute is referencing a non-existent method. The VM doesn't > care about such things, so execution should not be impacted (assuming > you can compile without explicitly referencing those classes). > > -Robert > > On 12/22/12 09:29, Brian Goetz wrote: >> Yes, Robert has run into something similar, and we're looking into it. >> It may be a compiler bug, but it definitely gets tickled with "make >> images" and not when just doing an ordinary "make" (and setting >> JAVA_HOME to the build/blah/jdk directory.) >> >> On 12/22/2012 12:25 PM, Marc Petit-Huguenin wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA256 >>> >>> I have this error when building the images, even from a fresh build directory, >>> and I do not know how to fix it: >>> >>> error: bad class file: >>> /home/petithug/lambda/build/linux-x86_64-normal-server-release/images/lib/rt.jar(java/util/stream/IntPipeline$1.class) >>> bad enclosing method attribute for class java.util.stream.IntPipeline$1 >>> Please remove or make sure it appears in the correct subdirectory of the >>> classpath. >>> >>> - -- >>> Marc Petit-Huguenin >>> Email: marc at petit-huguenin.org >>> Blog: http://blog.marc.petit-huguenin.org >>> Profile: http://www.linkedin.com/in/petithug >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.12 (GNU/Linux) >>> >>> iQIcBAEBCAAGBQJQ1ez5AAoJECnERZXWan7EHu8P/A7fCnz/HtAulqRkt0thaz1m >>> LZOo1jiFlIx0QL+mSE8loC5FPiLZGt5jW3oE5Ues6y4KYGPr++Z+t9qeN6e8aEWn >>> Ot+jpLiDD6/FpweKrg2BD8WAqYc984B6YZby2boc+yVQFwO+sY32h1XBW9Jfrpju >>> kk+Dyt/ZlreITBcmWsIlMSj+H4HIFC6vX83OpLj+GISG/vHUZQIOe8GN2vyC6E9G >>> INuy7KW+2BEv6MY84DaeSICMDlCvXpYnWLTTA7JVEyKhOoBL5K8uHlQ4Hm+2SbPy >>> 5iYfetooac6xZCmqgimxKVkFzoJkfcTJfINm55Wd85n/fA8inaFvtKZbxJA9qvLe >>> tTQvxrbjLPrvMFFnrZNB8rooxo8o8e3AVWW1bKLqXaAMGHqLqlCTtAC7j9J3H3Ln >>> 0qgqxMIdVFoVbrFIjJzcnjISEWm5gg4BaphcgsDtIIVdQqKpchPrysr3E439ym+S >>> gIkwGsGLd6M91RqZGLxpUTJi9g95aWr6uprfPZGayUjKcR2c2fsaXIx+8OESugpA >>> lkTbIUYv85oCxOh1c2ACnsopeMLVUK3H2PBeokRAB6BkcLWaaivP5PZj40Y5/QFS >>> dWWHUjaNFstSy+P8bpSlnPaUN1JsDaaw63+wkVNO7czJUsrFnLrUHjpOKEKDqb/6 >>> KVqBkLQniwdisk6UaDZo >>> =OLjz >>> -----END PGP SIGNATURE----- >>> > > From paul.sandoz at oracle.com Fri Dec 28 12:05:06 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 28 Dec 2012 20:05:06 +0000 Subject: hg: lambda/lambda/jdk: Merge NodeBuilder into Node as Node.Builder and Message-ID: <20121228200528.B161647433@hg.openjdk.java.net> Changeset: 0c20ef443a2b Author: psandoz Date: 2012-12-28 21:04 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/0c20ef443a2b Merge NodeBuilder into Node as Node.Builder and PrimitiveNodeBuilder into PrimitiveNode as PrimitiveNode.Builder. ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/NodeFactory.java ! src/share/classes/java/util/stream/ParallelPipelineHelper.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/op/IntermediateOp.java ! src/share/classes/java/util/stream/op/Node.java - src/share/classes/java/util/stream/op/NodeBuilder.java ! src/share/classes/java/util/stream/op/NodeUtils.java ! src/share/classes/java/util/stream/op/Nodes.java ! src/share/classes/java/util/stream/op/OpUtils.java ! src/share/classes/java/util/stream/primitive/IntNodeUtils.java ! src/share/classes/java/util/stream/primitive/IntNodes.java ! src/share/classes/java/util/stream/primitive/PrimitiveNode.java - src/share/classes/java/util/stream/primitive/PrimitiveNodeBuilder.java ! test-ng/tests/org/openjdk/tests/java/util/stream/OpTestCase.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ForEachOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/IntNodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeBuilderTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/NodeTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/ToArrayOpTest.java From peter.levart at gmail.com Fri Dec 28 14:22:00 2012 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 28 Dec 2012 23:22:00 +0100 Subject: hg: lambda/lambda/jdk: Renamings and reorganizations, mostly away from .primitive package into desired target locations In-Reply-To: <20121221224742.B43C74735B@hg.openjdk.java.net> References: <20121221224742.B43C74735B@hg.openjdk.java.net> Message-ID: <50DE1B88.5050301@gmail.com> Hi Brian, I think that the non-null check in 3 primitive variants of Optional is unnecessary (copy-paste bug?). For example: private final boolean isPresent; private final long value; private OptionalLong(long value) { this.isPresent = true; this.value = Objects.requireNonNull(value); } Regards, Peter On 12/21/2012 11:47 PM, brian.goetz at oracle.com wrote: > Changeset: 34d14e377743 > Author: briangoetz > Date: 2012-12-21 17:47 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/34d14e377743 > > Renamings and reorganizations, mostly away from .primitive package into desired target locations > > + src/share/classes/java/util/OptionalDouble.java > + src/share/classes/java/util/OptionalInt.java > + src/share/classes/java/util/OptionalLong.java > + src/share/classes/java/util/function/IntMultiFunction.java > + src/share/classes/java/util/stream/IntPipeline.java > + src/share/classes/java/util/stream/IntStream.java > ! src/share/classes/java/util/stream/ReferencePipeline.java > ! src/share/classes/java/util/stream/Stream.java > ! src/share/classes/java/util/stream/StreamShape.java > ! src/share/classes/java/util/stream/op/FindOp.java > - src/share/classes/java/util/stream/primitive/DoubleOptional.java > ! src/share/classes/java/util/stream/primitive/IntFoldOp.java > - src/share/classes/java/util/stream/primitive/IntMultiFunction.java > - src/share/classes/java/util/stream/primitive/IntMutableReducer.java > ! src/share/classes/java/util/stream/primitive/IntNodes.java > - src/share/classes/java/util/stream/primitive/IntOptional.java > - src/share/classes/java/util/stream/primitive/IntPipeline.java > ! src/share/classes/java/util/stream/primitive/IntSortedOp.java > - src/share/classes/java/util/stream/primitive/IntStream.java > - src/share/classes/java/util/stream/primitive/LongOptional.java > ! src/share/classes/java/util/stream/reduce/MutableReducer.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamLinkTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamReuseTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindAnyOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindFirstOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MatchOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntMinMaxTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntMultiMapOpTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntReduceTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamSpliteratorTest.java > ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java > > From brian.goetz at oracle.com Fri Dec 28 14:26:46 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 28 Dec 2012 17:26:46 -0500 Subject: hg: lambda/lambda/jdk: Renamings and reorganizations, mostly away from .primitive package into desired target locations In-Reply-To: <50DE1B88.5050301@gmail.com> References: <20121221224742.B43C74735B@hg.openjdk.java.net> <50DE1B88.5050301@gmail.com> Message-ID: <50DE1CA6.3010804@oracle.com> Thanks -- indeed a cut and paste bug. On 12/28/2012 5:22 PM, Peter Levart wrote: > Hi Brian, > > I think that the non-null check in 3 primitive variants of Optional is > unnecessary (copy-paste bug?). For example: > > private final boolean isPresent; > private final long value; > > private OptionalLong(long value) { > this.isPresent = true; > this.value = Objects.requireNonNull(value); > } > > > Regards, Peter > > On 12/21/2012 11:47 PM, brian.goetz at oracle.com wrote: >> Changeset: 34d14e377743 >> Author: briangoetz >> Date: 2012-12-21 17:47 -0500 >> URL:http://hg.openjdk.java.net/lambda/lambda/jdk/rev/34d14e377743 >> >> Renamings and reorganizations, mostly away from .primitive package into desired target locations >> >> + src/share/classes/java/util/OptionalDouble.java >> + src/share/classes/java/util/OptionalInt.java >> + src/share/classes/java/util/OptionalLong.java >> + src/share/classes/java/util/function/IntMultiFunction.java >> + src/share/classes/java/util/stream/IntPipeline.java >> + src/share/classes/java/util/stream/IntStream.java >> ! src/share/classes/java/util/stream/ReferencePipeline.java >> ! src/share/classes/java/util/stream/Stream.java >> ! src/share/classes/java/util/stream/StreamShape.java >> ! src/share/classes/java/util/stream/op/FindOp.java >> - src/share/classes/java/util/stream/primitive/DoubleOptional.java >> ! src/share/classes/java/util/stream/primitive/IntFoldOp.java >> - src/share/classes/java/util/stream/primitive/IntMultiFunction.java >> - src/share/classes/java/util/stream/primitive/IntMutableReducer.java >> ! src/share/classes/java/util/stream/primitive/IntNodes.java >> - src/share/classes/java/util/stream/primitive/IntOptional.java >> - src/share/classes/java/util/stream/primitive/IntPipeline.java >> ! src/share/classes/java/util/stream/primitive/IntSortedOp.java >> - src/share/classes/java/util/stream/primitive/IntStream.java >> - src/share/classes/java/util/stream/primitive/LongOptional.java >> ! src/share/classes/java/util/stream/reduce/MutableReducer.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamLinkTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamReuseTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/StreamTestScenario.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindAnyOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/FindFirstOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/op/MatchOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntMinMaxTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntMultiMapOpTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntReduceTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamSpliteratorTest.java >> ! test-ng/tests/org/openjdk/tests/java/util/stream/primitive/IntStreamTestScenario.java >> >> > From paul.sandoz at oracle.com Fri Dec 28 14:50:09 2012 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 28 Dec 2012 22:50:09 +0000 Subject: hg: lambda/lambda/jdk: Remove redundant null check for values. Message-ID: <20121228225031.5243047437@hg.openjdk.java.net> Changeset: ac067c84b69c Author: psandoz Date: 2012-12-28 23:46 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ac067c84b69c Remove redundant null check for values. ! src/share/classes/java/util/OptionalDouble.java ! src/share/classes/java/util/OptionalInt.java ! src/share/classes/java/util/OptionalLong.java From paul.sandoz at oracle.com Fri Dec 28 14:50:42 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 28 Dec 2012 23:50:42 +0100 Subject: hg: lambda/lambda/jdk: Renamings and reorganizations, mostly away from .primitive package into desired target locations In-Reply-To: <50DE1CA6.3010804@oracle.com> References: <20121221224742.B43C74735B@hg.openjdk.java.net> <50DE1B88.5050301@gmail.com> <50DE1CA6.3010804@oracle.com> Message-ID: <0DE078C1-FE3F-4193-ADBB-BAB7392528F9@oracle.com> On Dec 28, 2012, at 11:26 PM, Brian Goetz wrote: > Thanks -- indeed a cut and paste bug. > Fixed, thanks for reporting. Paul. > On 12/28/2012 5:22 PM, Peter Levart wrote: >> Hi Brian, >> >> I think that the non-null check in 3 primitive variants of Optional is >> unnecessary (copy-paste bug?). For example: >> >> private final boolean isPresent; >> private final long value; >> >> private OptionalLong(long value) { >> this.isPresent = true; >> this.value = Objects.requireNonNull(value); >> } >> >> >> Regards, Peter From brian.goetz at oracle.com Fri Dec 28 15:28:25 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 28 Dec 2012 23:28:25 +0000 Subject: hg: lambda/lambda/jdk: Fold IntFoldOp into FoldOp Message-ID: <20121228232838.2F15047439@hg.openjdk.java.net> Changeset: c1c21e403b6c Author: briangoetz Date: 2012-12-28 18:28 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/c1c21e403b6c Fold IntFoldOp into FoldOp ! src/share/classes/java/util/OptionalDouble.java ! src/share/classes/java/util/OptionalInt.java ! src/share/classes/java/util/OptionalLong.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/IntStream.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/op/FoldOp.java ! src/share/classes/java/util/stream/op/Ops.java - src/share/classes/java/util/stream/primitive/IntFoldOp.java ! src/share/classes/java/util/stream/reduce/Reducers.java From henry.jen at oracle.com Fri Dec 28 16:11:02 2012 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 28 Dec 2012 16:11:02 -0800 Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: References: <50D53C0A.6000203@oracle.com>, , , , <50DB9502.4090406@oracle.com>, , <50DCB236.4020709@oracle.com>, , Message-ID: <84D3ABF1-2D55-43F9-AF17-7439B36795DF@oracle.com> Jason, If I understand you correctly, there are two main concerns, 1. You want to encourage MessageFormat style logging, consider the other way is an anti-pattern. 2. The construction of message could be further eliminated when a filter is involved. Here is what I thought, For 1, the new API is simply enabling developer to provide a log message for the LogRecord, without forcing any formatting. In fact, because it's a Supplier, it actually enables all possibility about formatting. I can imagine all current MessageFormat style logging capability implemented as a Supplier. For 2, I don't disagree with you. However, as you said, it's worst case scenario when *all* handlers *never* try to call LogRecord.getMessage(). With serialization implications and compatibility concerns, we don't want to rush a change on LogRecord. Instead, current patch is simple and should be able to address many cases. Would it be good enough if we can defer the message construction after Logger.filter check, but construct the message before publish to Handlers? As Peter had pointed out earlier, we can add a reference in LogRecord to exchange for filtering at Logger level. But we cannot deferred further down to handler level without side-effects. Now again, for MessageFormat style logging, we don't lose any capability, and the laziness is already possible via proper use of parameters. The reason I don't include such a helper class for lambda to be used in parameter is that it's trivial. For parameter version, those should probably be customized to work with formatter anyway. I think it is reasonable to say the current patch is a step forward, and there are probably rooms to improve in the future. Next version I'll enable defer message construction until Logger filter check. Cheers, Henry On Dec 28, 2012, at 7:15 AM, Jason Mehrens wrote: > > Henry, > > It is beautiful if that code lives only inside of the logger and the caller is unaware of its existence. Same is true for writing a guard statement. > > The formatter can not always achieve the same laziness. If I converted your example in the API docs to be passed in the params argument I would have to evaluate it to a string before the logger call or create a supplier that overrides toString to return DiagnosisMessages.systemHealthStatus(). We are forcing caller to create the ugly code which the exact opposite of what you are trying to do with this patch. > > As soon as you use a MemoryHandler or install a Handler filter the levels will be the lowest number required. The problem is you end up throwing out or filtering out volumes of LogRecords that are never formatted. This is common when you are hunting for a specific error and what to see the last X number of messages that led up to the error. That was the technique used to reopen bug id 6840067. If I created a working proof of concept would that change anything or is this patch a done deal? > > Jason >> Subject: Re: RFR 2: JDK-8005263: Logging APIs takes Supplier for message >> From: henry.jen at oracle.com >> Date: Thu, 27 Dec 2012 18:24:17 -0800 >> CC: brian.goetz at oracle.com; lambda-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> To: jason_mehrens at hotmail.com >> >> As stated in the beginning of the review thread, the reason we don't have Supplier version for other API is that a formatter is involved and can achieve same laziness easily. >> >> The key is MessageFormatter can take arguments, which will be used to generate the output. As there is no directly support for Supplier, a possible solution is to have a wrapper class take a Supplier lambda, >> >> class Collector { >> final Supplier supplier; >> >> Collector(Supplier supplier) { >> this.supplier = supplier; >> } >> >> T collect() { >> return supplier.get(); >> } >> >> @Override >> String toString() { >> return supplier.get().toString(); >> } >> } >> >> It's not entirely beautiful, but is a general solution for applying supplier for MessageFormat. >> >> As the handler issue, I would argue that the logger would set to the lowest number required to be logged, i.e, at least one handler will format the message, thus the timing is not an real issue given the other caching/serialization concern discussed. >> >> Hope that helps, let me know if I missed something. >> >> Cheers, >> Henry >> >> >> On Dec 27, 2012, at 4:16 PM, Jason Mehrens wrote: >> >>> Brian, >>> >>> It's on my list too for lambdafying I just disagree with current implementation. I understand and agree that having to create a guard should not be required. It's awful to have to do. The point is that patch is still way too eager because you don't want to evaluate a message until the LogRecord arrives at a formatter inside of a handler. I don't want force anyone to use catalogs. I want to force everyone to use message parameterized logging (with or without a catalog) because it is powerful, lazy, and doesn't taste like a vegetable. If your concern is sugary sweets then, add overloaded methods that make message parameterized logging easy for the caller. If patch was rewritten like I proposed, it would be as terse as your example bellow. The difference is it would actually be lazy and would be useful when you need to create a custom filter to find some ghost in a production machine. Relevant or not, my patch would also enable lambdas and message catalogs. That is something that will never happen under the current patch. >>> >>> Jason >>> >>>> I think a significant fraction of the community would disagree with you. >>>> We ran a survey where we collected suggestions for lambdafying API >>>> methods, and this one came in top of the list. >>>> There is a significant fraction of the developer community that uses the >>>> logging API and doesn't care at all about localization, but does care >>>> about logging performance. One doesn't have to look very far to see >>>> that it is common practice to surround logging calls with >>>> >>>> if (logger.isLogging(level)) >>>> logger.log(level, msgExpr) >>>> >>>> to work around the eager evaluation. And such a practice is brittle, >>>> because it's easy to forget to do it in one place, and lose the benefit. >>>> Now, your answer might be "force all users to use message catalogs." >>>> But that's pretty mean. A lot of users really, really don't want to use >>>> message catalogs. They want to do: >>>> >>>> logger.log(level, () -> String.format(...)); >>>> >>>> You're basically saying we should force-feed those users some >>>> message-catalog vegetables, because it's good for them. >>> >>> >> From henry.jen at oracle.com Fri Dec 28 18:30:55 2012 From: henry.jen at oracle.com (Henry Jen) Date: Fri, 28 Dec 2012 18:30:55 -0800 Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <84D3ABF1-2D55-43F9-AF17-7439B36795DF@oracle.com> References: <50D53C0A.6000203@oracle.com>, , , , <50DB9502.4090406@oracle.com>, , <50DCB236.4020709@oracle.com>, , <84D3ABF1-2D55-43F9-AF17-7439B36795DF@oracle.com> Message-ID: <9378FC35-69A0-4152-9C91-102A1895460D@oracle.com> On Dec 28, 2012, at 4:11 PM, Henry Jen wrote: > Next version I'll enable defer message construction until Logger filter check. > On a second thought and after more reading into logging code in JDK, it seems like Filter is mostly applied to Handler instead of Logger, thus it's not really that beneficial. I also didn't find a way to configure Logger filter except programmed via setFilter API, that's another evidence that rarely a filter is applied to a Logger. There is no guarantee that Filter won't cause side-effect with lazy message construction on LogRecord although it's much less likely as Handler could do. Given all those factors, I don't think it's mature to implement. Cheers, Henry From brian.goetz at oracle.com Fri Dec 28 18:33:53 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sat, 29 Dec 2012 02:33:53 +0000 Subject: hg: lambda/lambda/jdk: Sort out the last unmerged terminal op Message-ID: <20121229023414.34DC74743E@hg.openjdk.java.net> Changeset: 63445bd8e457 Author: briangoetz Date: 2012-12-28 21:33 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/63445bd8e457 Sort out the last unmerged terminal op ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/op/FoldOp.java ! src/share/classes/java/util/stream/op/SortedOp.java ! src/share/classes/java/util/stream/op/UniqOp.java - src/share/classes/java/util/stream/primitive/IntSortedOp.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SortedOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UniqOpTest.java From brian.goetz at oracle.com Fri Dec 28 18:38:26 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sat, 29 Dec 2012 02:38:26 +0000 Subject: hg: lambda/lambda/jdk: Remove unused class Message-ID: <20121229023837.401FC4743F@hg.openjdk.java.net> Changeset: 3e268746e29f Author: briangoetz Date: 2012-12-28 21:38 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/3e268746e29f Remove unused class - src/share/classes/java/util/stream/StreamSource.java From marc at petit-huguenin.org Sat Dec 29 08:20:10 2012 From: marc at petit-huguenin.org (Marc Petit-Huguenin) Date: Sat, 29 Dec 2012 08:20:10 -0800 Subject: make images fails In-Reply-To: <50DDF4C2.5050703@oracle.com> References: <50D5ECFA.5050101@petit-huguenin.org> <50D5EDDD.2010308@oracle.com> <50D60C45.1010106@oracle.com> <50DDF4C2.5050703@oracle.com> Message-ID: <50DF183A.5040605@petit-huguenin.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 After a make clean, make images now works fine. Thanks. On 12/28/2012 11:36 AM, Brian Goetz wrote: > I've pushed a workaround that hopefully doesn't tickle this bug, while > we're waiting for a fix. > > On 12/22/2012 2:38 PM, Robert Field wrote: >> Yes, definitely a compiler bug. The lambda method isn't seen within the >> scope of the class, because it is synthetic, by the compiler on reading >> in of the class file, so it appears to the compiler that the enclosing >> method attribute is referencing a non-existent method. The VM doesn't >> care about such things, so execution should not be impacted (assuming you >> can compile without explicitly referencing those classes). >> >> -Robert >> >> On 12/22/12 09:29, Brian Goetz wrote: >>> Yes, Robert has run into something similar, and we're looking into it. >>> It may be a compiler bug, but it definitely gets tickled with "make >>> images" and not when just doing an ordinary "make" (and setting >>> JAVA_HOME to the build/blah/jdk directory.) >>> >>> On 12/22/2012 12:25 PM, Marc Petit-Huguenin wrote: > I have this error when building the images, even from a fresh build > directory, and I do not know how to fix it: > > error: bad class file: > /home/petithug/lambda/build/linux-x86_64-normal-server-release/images/lib/rt.jar(java/util/stream/IntPipeline$1.class) > > bad enclosing method attribute for class java.util.stream.IntPipeline$1 > Please remove or make sure it appears in the correct subdirectory of the > classpath. > >>>> >> >> > - -- Marc Petit-Huguenin Email: marc at petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQ3xg1AAoJECnERZXWan7EeI0P/jQTZ6K4yJRFtBK2dXlnNJRn tdDwNwyPgRHskCsgriFnUD/DZklqlGTPnIRBOfXjkGaJhski+bPJ4peQcyjFPJNi HrM1hT1gtYAT/dslRyOj1GiNGBOZUiKC28gngLFrRkP98D5bIJrhfD3WNt7Fi1sQ X4Uo3FleRCh66mtvf+H0patkyLqPz/A+yZFIjLOvoMHAZbCOUN04Yppz65XEWRyS tAjDyIX8spi2yb9CV2B+d+ifZ4586A617Djrqobhm38DSr3vgyJHhWrU17CycDuB 5urvduYguPndEuF4Fq4OH3dZmMGFdZSsyHPcWFR/MgnR/rBslD33VTYmoAoBI/3L eIKeheMgbPr4vo4qIGcPHibGUHbNNAdYQUCgOP1ksF+qmG/1o6jcTjqzTJ0LBRsT reoImqyh54m84XFff1KRs+yD/ByxHdYO5pC3JGa2bSMd1o7kOQYFQLa+ySucjp45 eeCEXGHhJqMLNSgym94QFrhoWeaolmCuruvVTN2G8RqZg4vUDSTuuIz1jRQcBQwk pJErI3YYPa1GHEHngKElsp41fSRh0AqrhFdNyR9G2+DC6lt0g4jctRpdSElloLsV 0/Xu/J1ebBAmjsg3QCzj3Dn/eDrKtVaD0ApsgiUS/sgLC7vUwzslvk/7uQjMWFPO 9uIq48bUl0z+N5EqykGv =2BUG -----END PGP SIGNATURE----- From sam at sampullara.com Sat Dec 29 21:39:00 2012 From: sam at sampullara.com (Sam Pullara) Date: Sat, 29 Dec 2012 21:39:00 -0800 Subject: New and exciting error in the latest compiler Message-ID: Here is the code: https://github.com/spullara/java-future-jdk8/blob/master/src/main/java/spullara/util/Currier.java https://github.com/spullara/java-future-jdk8/blob/master/src/test/java/spullara/util/CurrierTest.java Gives an ambiguity when I think it should be straightforward to pick the right one based on arity of the method reference: error: reference to curry is ambiguous both method curry(C2,U#1) in Currier and method curry(C1,U#2) in Currier match where T#1,U#1,V,T#2,U#2 are type-variables: T#1 extends Object declared in method curry(C2,U#1) U#1 extends Object declared in method curry(C2,U#1) V extends Object declared in method curry(C2,U#1) T#2 extends Object declared in method curry(C1,U#2) U#2 extends Object declared in method curry(C1,U#2) error: reference to curry is ambiguous both method curry(C2,U#1) in Currier and method curry(C1,U#2) in Currier match where T#1,U#1,V,T#2,U#2 are type-variables: T#1 extends Object declared in method curry(C2,U#1) U#1 extends Object declared in method curry(C2,U#1) V extends Object declared in method curry(C2,U#1) T#2 extends Object declared in method curry(C1,U#2) U#2 extends Object declared in method curry(C1,U#2) And those error messages have to be fixed, they are brutal :) Sam From daniel.kristensen at gmail.com Sun Dec 30 07:55:54 2012 From: daniel.kristensen at gmail.com (Daniel Kristensen) Date: Sun, 30 Dec 2012 16:55:54 +0100 Subject: Stream of infinite number of elements Message-ID: Hi, Did you consider pushing the strict operations to a sub-interface of Stream. A few examples of where methods would go: public interface Stream extends BaseStream { Stream filter(Predicate predicate); Stream map(Mapper mapper); ... FiniteStream limit(int n); ... } public interface FiniteStream extends Stream { FiniteStream sorted(Comparator comparator); void forEach(Block block); > A into(A target); Object[] toArray(); ... } This would increase type safety, and would remove the needto document in javadoc whether methods that take streams as parameters require them to be finite etc. Of course a drawback would be that FiniteStream is not quite as nicely succinct as Stream. Best regards Daniel > Message: 6 > Date: Fri, 28 Dec 2012 17:14:12 +0100 > From: Paul Sandoz > Subject: Re: Stream of infinite number of elements > Cc: lambda-dev at openjdk.java.net > Message-ID: > Content-Type: text/plain; charset=us-ascii > > On Dec 26, 2012, at 3:23 PM, Denis DEBARBIEUX > wrote: > > Hi all, > > > > To implement the interface /Stream/, I have to implement methods like > > /max, min, sorted/. > > > > What is expected by the interface when my stream is infinite? > Undetermined behaviour, unless those terminal operations are prefixed with > an intermediate limit operation. > The first two might never return and the latter one will most likely throw > an OOE. > > > Throw an > > exception (does the interface provide an InfiniteStreamException?) or > > implement them as an any time algorithm? > > > We are considering a cancel or while operation that on say a met temporal > condition will ensure no more elements are available, thus > non-short-circuit terminal operations should terminate under such > conditions. > Originally we tried to detect cases when an infinite stream was hooked up > to something that would be known to not terminate but we cannot capture all > such cases so rather than partially supporting this we decided to go for > the "developer beware" option. > Paul. From brian.goetz at oracle.com Sun Dec 30 08:45:02 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 30 Dec 2012 11:45:02 -0500 Subject: Stream of infinite number of elements In-Reply-To: References: Message-ID: <50E06F8E.7090209@oracle.com> Yes we did! On 12/30/2012 10:55 AM, Daniel Kristensen wrote: > Hi, > > Did you consider pushing the strict operations to a sub-interface of > Stream. A few examples of where methods would go: > > public interface Stream extends BaseStream { > > Stream filter(Predicate predicate); > > Stream map(Mapper mapper); > > ... > > FiniteStream limit(int n); > > ... > > } > > > public interface FiniteStream extends Stream { > > FiniteStream sorted(Comparator comparator); > > void forEach(Block block); > > > A into(A target); > > Object[] toArray(); > > ... > > } > > > This would increase type safety, and would remove the needto document > in javadoc whether methods that take streams as parameters require > them to be finite etc. > > > Of course a drawback would be that FiniteStream is not quite as nicely > succinct as Stream. > > > Best regards > > Daniel > > > > >> Message: 6 >> Date: Fri, 28 Dec 2012 17:14:12 +0100 >> From: Paul Sandoz >> Subject: Re: Stream of infinite number of elements >> Cc: lambda-dev at openjdk.java.net >> Message-ID: >> Content-Type: text/plain; charset=us-ascii >> >> On Dec 26, 2012, at 3:23 PM, Denis DEBARBIEUX >> wrote: >>> Hi all, >>> >>> To implement the interface /Stream/, I have to implement methods like >>> /max, min, sorted/. >>> >>> What is expected by the interface when my stream is infinite? >> Undetermined behaviour, unless those terminal operations are prefixed with >> an intermediate limit operation. >> The first two might never return and the latter one will most likely throw >> an OOE. >> >>> Throw an >>> exception (does the interface provide an InfiniteStreamException?) or >>> implement them as an any time algorithm? >>> >> We are considering a cancel or while operation that on say a met temporal >> condition will ensure no more elements are available, thus >> non-short-circuit terminal operations should terminate under such >> conditions. >> Originally we tried to detect cases when an infinite stream was hooked up >> to something that would be known to not terminate but we cannot capture all >> such cases so rather than partially supporting this we decided to go for >> the "developer beware" option. >> Paul. > From brian.goetz at oracle.com Sun Dec 30 10:31:26 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sun, 30 Dec 2012 18:31:26 +0000 Subject: hg: lambda/lambda/jdk: Consolidate PipelineHelper and ParallelPipelineHelper Message-ID: <20121230183138.127AD4745F@hg.openjdk.java.net> Changeset: 6d9bcc7d49d3 Author: briangoetz Date: 2012-12-30 13:31 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6d9bcc7d49d3 Consolidate PipelineHelper and ParallelPipelineHelper ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/IntPipeline.java - src/share/classes/java/util/stream/ParallelPipelineHelper.java ! src/share/classes/java/util/stream/PipelineHelper.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/StreamShape.java ! src/share/classes/java/util/stream/StreamShapeFactory.java ! src/share/classes/java/util/stream/op/AbstractShortCircuitTask.java ! src/share/classes/java/util/stream/op/AbstractTask.java ! src/share/classes/java/util/stream/op/CollectorOps.java ! src/share/classes/java/util/stream/op/FindOp.java ! src/share/classes/java/util/stream/op/FoldOp.java ! src/share/classes/java/util/stream/op/ForEachOp.java ! src/share/classes/java/util/stream/op/IntermediateOp.java ! src/share/classes/java/util/stream/op/MatchOp.java ! src/share/classes/java/util/stream/op/NodeUtils.java ! src/share/classes/java/util/stream/op/OpUtils.java ! src/share/classes/java/util/stream/op/SliceOp.java ! src/share/classes/java/util/stream/op/SortedOp.java ! src/share/classes/java/util/stream/op/StreamOp.java ! src/share/classes/java/util/stream/op/UniqOp.java ! src/share/classes/java/util/stream/primitive/IntNodeUtils.java ! src/share/classes/java/util/stream/primitive/PrimitiveNodes.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/SortedOpTest.java ! test-ng/tests/org/openjdk/tests/java/util/stream/op/UniqOpTest.java From brian.goetz at oracle.com Sun Dec 30 10:47:04 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sun, 30 Dec 2012 18:47:04 +0000 Subject: hg: lambda/lambda/jdk: Follow-on cleanups in StreamShapeFactory Message-ID: <20121230184715.72EFB47460@hg.openjdk.java.net> Changeset: d83e48d71fda Author: briangoetz Date: 2012-12-30 13:46 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d83e48d71fda Follow-on cleanups in StreamShapeFactory ! src/share/classes/java/util/stream/StreamShapeFactory.java From mcnepp02 at googlemail.com Mon Dec 31 09:27:35 2012 From: mcnepp02 at googlemail.com (Gernot Neppert) Date: Mon, 31 Dec 2012 18:27:35 +0100 Subject: Looking forward to 2013 Message-ID: <50E1CB07.2090508@googlemail.com> Hello all, I'm off to New Year's Eve party now, and I just wanted to thank everybody who's been actively involved in JDK-8 development for the great work they have done in 2012! - The stabilization of the lambda syntax seems almost complete - the same goes for default methods on interfaces! - the "lambdafication" of the JDK libraries has come very far - the availability of lambda-aware binary JDK-snapshots has brought this whole new exciting feature to the attention of early-adopters who just didn't want to go the extra mile and compile the entire JDK. I'm not sure whether lambdas will actually revolutionize programming in Java, but they are defintiely going to to make it even more fun than it is now!! Have a great 2013! From brian.goetz at oracle.com Mon Dec 31 10:47:29 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 31 Dec 2012 18:47:29 +0000 Subject: hg: lambda/lambda/jdk: Add Random.ints() stream generator Message-ID: <20121231184801.BEAB547475@hg.openjdk.java.net> Changeset: ce65d7bd0b41 Author: briangoetz Date: 2012-12-31 13:47 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ce65d7bd0b41 Add Random.ints() stream generator ! src/share/classes/java/util/Random.java + test-ng/tests/org/openjdk/tests/java/util/RandomStreamTest.java From boaznahum at gmail.com Mon Dec 31 10:50:02 2012 From: boaznahum at gmail.com (Boaz Nahum) Date: Mon, 31 Dec 2012 10:50:02 -0800 Subject: From Function to t Predicate - What is preferred ? Message-ID: So Predicate is not Function class Iters { static boolean beginWithA(String s) { return s.startsWith("a"); } } Function map = Iters::beginWithA; Should we Predicate filter = Iters::beginWithA; Or this is not too bad: Predicate filter = map::apply Will optimization come to rescue us in the second case Thanks Boaz From brian.goetz at oracle.com Mon Dec 31 11:00:59 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 31 Dec 2012 14:00:59 -0500 Subject: From Function to t Predicate - What is preferred ? In-Reply-To: References: Message-ID: <50E1E0EB.7020602@oracle.com> There is a lot of flexibility permitted when adapting method references to functional interfaces, for this very reason. So Iters::beginsWithA should easily convert to either a Predicate or a Function. Capturing a stateless lambda (static method reference, unbound instance method reference, or lambda that captures nothing from the environment) is basically free. Capturing a bound method reference or stateful lambda is (currently) exactly as costly as creating an inner class instance. In the future, we may well be able to optimize these capture costs; we have a lot of plans on the drawing board, but the implementation strategy for 8 has already converged. So for the time being, capturing map::apply is an object creation, whereas capturing Iters::beginWithA is not. On 12/31/2012 1:50 PM, Boaz Nahum wrote: > So Predicate is not Function > > class Iters { > > static boolean beginWithA(String s) { > return s.startsWith("a"); > } > } > > Function map = Iters::beginWithA; > > Should we > > Predicate filter = Iters::beginWithA; > > Or this is not too bad: > Predicate filter = map::apply > > Will optimization come to rescue us in the second case > > Thanks > Boaz > From brian.goetz at oracle.com Mon Dec 31 12:26:10 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 31 Dec 2012 20:26:10 +0000 Subject: hg: lambda/lambda/jdk: Add ints() stream generator to ThreadLocalRandom Message-ID: <20121231202630.B8F1D47477@hg.openjdk.java.net> Changeset: 858e2f478d62 Author: briangoetz Date: 2012-12-31 15:26 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/858e2f478d62 Add ints() stream generator to ThreadLocalRandom ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java ! test-ng/tests/org/openjdk/tests/java/util/RandomStreamTest.java From jason_mehrens at hotmail.com Sat Dec 22 07:30:59 2012 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Sat, 22 Dec 2012 15:30:59 -0000 Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message In-Reply-To: <50D53C0A.6000203@oracle.com> References: <50D53C0A.6000203@oracle.com> Message-ID: The msg argument in most cases is a string literal because it is either a resource bundle key or a MessageFormat literal. The established best practice is to convert on the fly construction of messages to use the MessageFormat syle logging. This current patch is kind of anti-pattern of that practice. I would think the real win would be to delay construction of the 'params' argument in the logging framework. Allowing the callers to write logger.log(level, "{0}", Foo::bar) and have the call to bar be lazy eval would be the best of both the logging world and the lambda world. Jason > Date: Fri, 21 Dec 2012 20:50:18 -0800 > From: henry.jen at oracle.com > To: core-libs-dev at openjdk.java.net; lambda-dev at openjdk.java.net > Subject: RFR 2: JDK-8005263: Logging APIs takes Supplier for message > > Hi, > > Update patch with review feedback, > - JavaDoc update for benefit and gotcha. > - logEx/logpEx is not log/logp with Supplier as last argument. > As a matter of fact, all API with Supplier takes it as last > argument. > - No more doLog(Level, Supplier, Block) helper for > performance concerns. > > Specdiff and webrev can be found at following, > > http://cr.openjdk.java.net/~henryjen/ccc/8005263.1/specdiff/diff.html > http://cr.openjdk.java.net/~henryjen/ccc/8005263.1/webrev/ > > Cheers, > Henry >