From scolebourne at joda.org Sat Oct 1 03:38:11 2011 From: scolebourne at joda.org (Stephen Colebourne) Date: Sat, 1 Oct 2011 11:38:11 +0100 Subject: Syntax decision In-Reply-To: <4E865E01.9030900@oracle.com> References: <4E8556E7.2020206@gmail.com> <4E863CEF.6000005@oracle.com> <4E865E01.9030900@oracle.com> Message-ID: On 1 October 2011 01:25, Brian Goetz wrote: > The only thing going for the strawman syntax was that if you squinted > and pronounced # as "method", it looked like the method declaration > syntax. Oh and it was the most "logical", as you say yourself. Basically, the strawman syntax was derived from FCM. I introduced the syntax with an example of a comparator (formatted on multiple lines) with the comment "This syntax is termed an anonymous inner method, and is a logical extension to the anonymous inner class concept". And further described as: "With FCM, we chose to use the # symbol as our key syntactic element. There were a number of reasons. Firstly, # is unused in Java at present. This means that there are no conflicts within the parser, simplifying the proposal. It also means that someone reading the resulting code doesn't have to think about what the symbol means (unlike ?, <, > or : for example). The # has been used by Java developers before however, as it is used in Javadoc. It has been pointed out that in most, if not all, cases, the parser could work out the meaning of the code without the use of the symbol at all. This is true, but a key feature of Java is readability. We believe that in this case, the extra symbol adds to the readability by clearly identifying the method syntax. This is important for inner methods which are likely to be running in another thread, hence the # acts as a kind of warning." Thus the syntax picked itself - start from method references String#concat. treat #foo as being this#foo where #foo is a reference to foo, thus # on its own is a reference to some code without a name (anonymous). Then, add method arguments and block. The # also acted as a very visual "capture" when searching for where the "return" statement returns to, something that I find harder with an arrow. The importance of the return point depends like much of this on whether you believe that expression or multi-line statement lambdas will be most common. Note that #()(expr) was never in FCM and I never supported it (it looks and reads very badly), but I would have supported #() expr. To emphasise, the # linked the method reference and inner method (lambda) parts together for learners, something which has been lost now. I also found, as Stuart did, that the {-> expr} and {-> stmt;} forms differing only by a semicolon was a recipe for trouble. Personally, I find the selected syntax OK, but not great, except in the x -> expr form. Thats because I dislike the way that the argument brackets blend into the method parameter brackets when passing to a method as in sort((a,b) -> a - b). I always find its the blending of similar characters that is hardest to read, and why # was useful punctuation. Thats also why I might well prefer a Ruby-like sort(|a,b| a - b), because the characters do not blend in the same way. But anyway, I'm sure we'll get used to it. Stephen > ?But, it was broadly hated for so many reasons, including: > ?- Some people just hated the #, it felt like being hit over the head > with a hammer labeled "watch out, something new and different here!" > ?- Some people had a hard time seeing #(x)(x) as one expression, rather > than two > ?- Visual confusion with casts. > > While all the options had supporters and detractors, strawman elicited > the strongest negative reaction from its detractors. ?If you look at the > "too terse and too alien" thread from June 2010, you'll see some initial > reactions from this group. ?While people later softened their stance > (likely through familiarity), the negative reactions were just too strong. > > Basically, while it might have been the most "logical" syntax, we're not > logical beings. > > From talden at gmail.com Sat Oct 1 04:16:11 2011 From: talden at gmail.com (Talden) Date: Sun, 2 Oct 2011 00:16:11 +1300 Subject: Syntax decision In-Reply-To: References: <4E8556E7.2020206@gmail.com> <4E863CEF.6000005@oracle.com> <4E865E01.9030900@oracle.com> Message-ID: On Sat, Oct 1, 2011 at 11:38 PM, Stephen Colebourne wrote: > Personally, I find the selected syntax OK, but not great, except in > the x -> expr form. Thats because I dislike the way that the argument > brackets blend into the method parameter brackets when passing to a > method as in sort((a,b) -> a - b). I always find its the blending of > similar characters that is hardest to read, and why # was useful > punctuation. Thats also why I might well prefer a Ruby-like sort(|a,b| > a - b), because the characters do not blend in the same way. This is where I'm at. Lambdas may be delayed execution or executed on another or many threads, they _shouldn't_ blend into their surroundings in the manner of other sequentially executed code. > But anyway, I'm sure we'll get used to it. I'm sure we'll get used to it, I'm also sure we'll get used to occasionally overlooking the parentheses and '->' construct amongst other expression text. I would have liked the syntax choice to do more towards preventing that (especially with the eleventy bazillion different ways Lambda code will get parenthesised, whitespaced, line-broken and identified). I think it will prove noticeable in my future recruitment efforts that the hill for future Java developers (and a lot of current ones) has become at least slightly unnecessarily steeper (it's steeper anyway of course, maybe the slight increase in grade isn't enough to detrimentally affect future java market traction). -- Aaron Scott-Boddendijk From brian.goetz at oracle.com Sat Oct 1 14:26:52 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 01 Oct 2011 17:26:52 -0400 Subject: Syntax decision In-Reply-To: References: <4E8556E7.2020206@gmail.com> <4E863CEF.6000005@oracle.com> <4E865E01.9030900@oracle.com> Message-ID: <4E87859C.5070709@oracle.com> > On 1 October 2011 01:25, Brian Goetz wrote: >> The only thing going for the strawman syntax was that if you squinted >> and pronounced # as "method", it looked like the method declaration >> syntax. > > Oh and it was the most "logical", as you say yourself. I think you have misunderstood my use of the scare-quotes. When you wrap a word like "logical" with quotes, it doesn't mean the same thing as without. (Though explaining this is made harder by the fact that its confusing to use quotes and talk about quotes in the same sentence.) The key part of the explanation was: "broadly hated." From brian.goetz at oracle.com Sat Oct 1 14:31:24 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Sat, 01 Oct 2011 17:31:24 -0400 Subject: Syntax decision In-Reply-To: References: <4E8556E7.2020206@gmail.com> <4E863CEF.6000005@oracle.com> <4E865E01.9030900@oracle.com> Message-ID: <4E8786AC.90304@oracle.com> >> Personally, I find the selected syntax OK, but not great, except in >> the x -> expr form. Thats because I dislike the way that the argument >> brackets blend into the method parameter brackets when passing to a >> method as in sort((a,b) -> a - b). I always find its the blending of >> similar characters that is hardest to read, and why # was useful >> punctuation. Thats also why I might well prefer a Ruby-like sort(|a,b| >> a - b), because the characters do not blend in the same way. > > This is where I'm at. Lambdas may be delayed execution or executed on > another or many threads, they _shouldn't_ blend into their > surroundings in the manner of other sequentially executed code. The feeling in the expert group was that this is something that is going to change over time. It is tempting to make lambdas look really different because delayed evaluation is new NOW, but it doesn't take long before that difference looks like a hammer over the head. In this case, the hammer was the kind with a waffle pattern on its head, shaped like #. The reality is: there's no perfect syntax; if there was, we'd surely have found it. What looks beautiful to one person is too subtle to another. We picked something that we thought was good, and which has been shown to work in other Java-like languages. From maurizio.cimadamore at oracle.com Mon Oct 3 04:11:33 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 03 Oct 2011 12:11:33 +0100 Subject: Syntax decision In-Reply-To: <1317223451.31622.YahooMailNeo@web160717.mail.bf1.yahoo.com> References: <4E692067.1080509@oracle.com> <4E822196.10801@oracle.com> <4E83320D.8000503@oracle.com> <1317223451.31622.YahooMailNeo@web160717.mail.bf1.yahoo.com> Message-ID: <4E899865.1010703@oracle.com> On 28/09/11 16:24, Henri Gerrits wrote: > Since the cast syntax can't be touched, one way out could be to change the arg delimiters for the lambda, e.g.; > > |x, y| -> x + y; Note that a Ruby-like syntax using '|' as parameters delimiter is probably not gonna fly should we add support for union types (as the current prototype does): |List|-> ... makes it very awkward to read. Maurizio > Personally, I find this a bit more readable when the lambda is provided as an argument to a method or constructor: > > c.sort(|x, y| -> x> y); > > instead of: > > c.sort((x, y) -> x> y); > > But I'm sure you will already have considered (and rejected) '|'. > > Henri > > > ----- Original Message ----- >> From: Brian Goetz >> To: Howard Lovatt >> Cc: "lambda-dev at openjdk.java.net" >> Sent: Wednesday, September 28, 2011 10:41 AM >> Subject: Re: Syntax decision >> >> T he nilary syntax is still a thorn. But the obvious solution outlined >> below -- allow elision of the () -- leads to a syntactic ambiguity. If >> -> { statement; } were a valid lambda, then is: >> >> (identifier) -> { statement; } >> >> a one-arg lambda with inferred type, or a cast of a nilary lambda? >> >> If people have brilliant other suggestions for nilary lambda syntax, >> we'd consider it. >> >> >> >> On 9/28/2011 2:03 AM, Howard Lovatt wrote: >>> Personally I am glad you have decided to go with -> since I have had >>> trouble reading Scala code, however this is not my main point in this >>> post which is have you decided if you require () for no arguments or if >>> you plan to allow a 'naked' -> e.g.: >>> >>> shortCutAnd( -> size>= 0, -> size< max ); // Example >> equivalent >>> to size>= 0&& size< max, but user written >>> >>> On 28 September 2011 05:18, Brian Goetz>> > wrote: >>> >>> Update on syntax: the EG has chosen to stick with the -> form of the >>> arrow that the prototype currently uses, rather than adopt the =>. >>> >>> You could think of this in two ways (I'm sure I'll hear both): >>> >>> - This is much better, as it avoids some really bad interactions with >>> existing operators, such as: >>> >>> x => x.age<= 0; // duelling arrows >>> or >>> Predicate p = x => x.size == 0; // duelling equals >>> >>> - What a bunch of idiots we are, in that we claimed the goal of doing >>> what other languages did, and then made gratuitous changes "just >> for the >>> sake of doing something different". >>> >>> Obviously we don't think we're idiots, but everyone can have an >>> opinion :) >>> >>> In the end, this was viewed as a small tweak to avoid some undesirable >>> interactions, while preserving the overall goal of "mostly looks >> like >>> what lambdas look like in other similar languages." >>> >>> >>> >>> On 9/8/2011 4:07 PM, Brian Goetz wrote: >>> > This just in: the EG has (mostly) made a decision on syntax. >>> > >>> > After considering a number of alternatives, we decided to >> essentially >>> > adopt the C# syntax. We may still deliberate further on the fine >>> points >>> > (e.g., thin arrow vs fat arrow, special nilary form, etc), and >>> have not >>> > yet come to a decision on method reference syntax. >>> > >>> > The C# syntax is: >>> > >>> > lambda = ArgList Arrow Body >>> > ArgList = Identifier >>> > | "(" Identifier [ "," >> Identifier ]* ")" >>> > | "(" Type Identifier [ "," Type >> Identifier ]* ")" >>> > Body = Expression >>> > | "{" [ Statement ";" ]+ >> "}" >>> > >>> > Here are some examples of lambda expressions using this syntax: >>> > >>> > x => x + 1 >>> > (x) => x + 1 >>> > (int x) => x + 1 >>> > (int x, int y) => x + y >>> > (x, y) => x + y >>> > (x, y) => { System.out.printf("%d + %d = %d%n", >> x, y, x+y); } >>> > () => { System.out.println("I am a Runnable"); } >>> > >>> > The decision to choose this syntax was twofold: >>> > - The syntax scores "pretty well" on most subjective >> measures >>> (though >>> > has cases where it looks bad, just like all the others do). In >>> > particular, it does well with "small" lambdas that are >> used as method >>> > arguments (a common case), and also does well with large >>> > (multi-statement) lambdas. >>> > >>> > - Despite extensive searching, there was no clear winner among >> the >>> > alternatives (each form had some good aspects and some really not >>> very >>> > good aspects, and there was no form that was clearly better than >> the >>> > others). So, we felt that it was better to choose something that >> has >>> > already been shown to work well in the two languages that are >>> most like >>> > Java -- C# and Scala -- rather than to invent something new. >>> > >>> > A compiler implementation should be available soon. >>> > >>> > >>> > >>> >>> >>> >>> >>> -- >>> -- Howard. >>> From isidore at setgame.com Mon Oct 3 10:07:35 2011 From: isidore at setgame.com (Llewellyn Falco) Date: Mon, 3 Oct 2011 10:07:35 -0700 Subject: Syntax decision In-Reply-To: References: <4E8556E7.2020206@gmail.com> <4E863CEF.6000005@oracle.com> <4E865E01.9030900@oracle.com> Message-ID: > On Sat, Oct 1, 2011 at 11:38 PM, Stephen Colebourne > wrote: > > Personally, I find the selected syntax OK, but not great, except in > > the x -> expr form. Thats because I dislike the way that the argument > > brackets blend into the method parameter brackets when passing to a > > method as in sort((a,b) -> a - b). I always find its the blending of > > similar characters that is hardest to read, and why # was useful > > punctuation. Thats also why I might well prefer a Ruby-like sort(|a,b| > > a - b), because the characters do not blend in the same way. > -- > Maybe it's because I am SO use to lambdas in C#, but I have to disagree with the "blending" comment. In fact I had to re-read this paragraph a couple of times because I saw sort(|a,b|a - b) as sort(Ia,bIa - b) and didn't understand how it was a lambda? actually even side by side it's a bit hard for me to see the difference now. perhaps it is my font.... allow me to change the second example to lowercase.... sort(|a,b|a - b) as sort(ia,bia - b) there, that's easier to see. anyways, of bigger concern to me is there still seems to be a profound misunderstanding of the purpose of lambdas on this expert thread. lambdas do not offer ANY new functionality to java, they are just an alternative syntax to enable the open-closed principle. and they allow people to chose to remove duplication, where otherwise they would not. example: summing up the length of characters in a string the lambda example of this is names.sum( (n)->n.length); easy choice, most of us would do it, but, this is completely allowed by the current java framework, just without the syntax names.sum( new Func(){ public Integer extract(String n){ return n.length; } } ); of course that is messy, so it might be easier to write int sum = 0; for(String n : names) { sum += n.length; } and now we stop favoring the open closed principle in favor of massive duplication. (if you doubt that I am right about the human nature of this, do a quick search in the standard java libraries for a forloop....) lambdas allow us to remove duplication, one of the most important of design principles. Once we do that, we start to see the profund effects it has, just how much duplication exists in our code, and how many 'patterns' we have. Entire frameworks start to pop up when we realize this composibility that open/closed has provided. but this isn't because lambda's have added that functionality, they have not! They have merely made the choice cheap enough that we actually use it. Llewellyn Falco www.approvaltests.com www.teachingkidsprogramming.org From brian.goetz at oracle.com Wed Oct 5 09:22:48 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 05 Oct 2011 16:22:48 +0000 Subject: hg: lambda/defender-prototype: Initial repopulation of repo Message-ID: <20111005162248.C552F47C04@hg.openjdk.java.net> Changeset: cfaa352d58e3 Author: briangoetz Date: 2011-10-05 12:22 -0400 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/cfaa352d58e3 Initial repopulation of repo + .classpath + .hgignore + .project + Agent.iml + Defender-prototype.iml + build.xml + doc/featherweight-defenders.aux + doc/featherweight-defenders.log + doc/featherweight-defenders.pdf + doc/featherweight-defenders.synctex.gz + doc/featherweight-defenders.tex + doc/usage.txt + nbproject/project.xml + src/jsr335/agent/Agent.java + src/jsr335/agent/AgentClassModelMap.java + src/jsr335/agent/ClassKey.java + src/jsr335/agent/ClassModel.java + src/jsr335/agent/ClassModelMap.java + src/jsr335/agent/ComputeWeaves.java + src/jsr335/agent/DefenderAttribute.java + src/jsr335/agent/MappingVisitor.java + src/jsr335/agent/Method.java + src/jsr335/agent/ProjectedMethod.java + src/jsr335/agent/RawMethod.java + src/jsr335/agent/Weave.java + src/jsr335/agent/WeaveClassVisitor.java + src/jsr335/agent/batch/BatchClassModelMap.java + src/jsr335/agent/batch/BatchExecute.java + src/jsr335/agent/batch/Entry.java + src/jsr335/agent/batch/FileEntry.java + src/jsr335/agent/batch/JarFileEntry.java + src/jsr335/agent/batch/JdkEntry.java + src/jsr335/agent/batch/Main.java + src/jsr335/agent/generic/ArrayDType.java + src/jsr335/agent/generic/ClassDType.java + src/jsr335/agent/generic/ClassDescriptor.java + src/jsr335/agent/generic/DType.java + src/jsr335/agent/generic/DTypeVariable.java + src/jsr335/agent/generic/MethodDescriptor.java + src/jsr335/agent/generic/PrimitiveDType.java + src/jsr335/agent/generic/SignatureReader.java + src/jsr335/agent/generic/TypeVariableDecl.java + src/jsr335/agent/generic/TypeVariableMap.java + src/jsr335/agent/generic/WildCardMinusDType.java + src/jsr335/agent/generic/WildCardPlusDType.java + src/jsr335/agent/generic/WildCardStarDType.java + src/jsr335/agent/runtime/WeaveFailure.java + src/jsr335/agent/runtime/Woven.java + test/jsr335/agent/testng/BridgeTest.java + test/jsr335/agent/testng/CovariantOverrideTest.java + test/jsr335/agent/testng/DefenderTestCase.java + test/jsr335/agent/testng/DualingTest.java + test/jsr335/agent/testng/ErasedGenericTest.java + test/jsr335/agent/testng/GenericTest.java + test/jsr335/agent/testng/Implementations.java + test/jsr335/agent/testng/InnerGenericTest.java + test/jsr335/agent/testng/LocalClassTest.java + test/jsr335/agent/testng/MultipleInheritanceTest.java + test/jsr335/agent/testng/ReabstractionTest.java + test/jsr335/agent/testng/ShadowTest.java + test/jsr335/agent/testng/SimpleDefenderTest.java + testgen/jsr335/test/shapegen/ClassCase.java + testgen/jsr335/test/shapegen/FDTest.java + testgen/jsr335/test/shapegen/Hierarchy.java + testgen/jsr335/test/shapegen/HierarchyGenerator.java + testgen/jsr335/test/shapegen/Rule.java + testgen/jsr335/test/shapegen/RuleGroup.java + testgen/jsr335/test/shapegen/TTNode.java + testgen/jsr335/test/shapegen/TTParser.java + testgen/jsr335/test/shapegen/TTShape.java From brian.goetz at oracle.com Wed Oct 5 09:25:01 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 05 Oct 2011 16:25:01 +0000 Subject: hg: lambda/defender-prototype: Remove temporary doc files Message-ID: <20111005162501.6134747C05@hg.openjdk.java.net> Changeset: 251e40bf113b Author: briangoetz Date: 2011-10-05 12:24 -0400 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/251e40bf113b Remove temporary doc files - doc/featherweight-defenders.aux - doc/featherweight-defenders.log - doc/featherweight-defenders.synctex.gz From brian.goetz at oracle.com Wed Oct 5 09:55:58 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 05 Oct 2011 16:55:58 +0000 Subject: hg: lambda/defender-prototype: Fix local varible table offset bugs when weaving defenders with long/double arguments Message-ID: <20111005165558.770EC47C07@hg.openjdk.java.net> Changeset: fa3d8be9db59 Author: briangoetz Date: 2011-10-05 12:55 -0400 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/fa3d8be9db59 Fix local varible table offset bugs when weaving defenders with long/double arguments ! .hgignore ! src/jsr335/agent/WeaveClassVisitor.java + test/jsr335/agent/testng/OffsetRegTest.java From jim.holmlund at sun.com Wed Oct 5 12:49:03 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Wed, 05 Oct 2011 19:49:03 +0000 Subject: hg: lambda/lambda/jdk: s/isEmpty/isEmptyPath/ to avoid conflict with new Iterable.isEmpty() method Message-ID: <20111005194928.2BE1A47C0F@hg.openjdk.java.net> Changeset: b9c8c6dd22b0 Author: jjh Date: 2011-10-05 12:46 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b9c8c6dd22b0 s/isEmpty/isEmptyPath/ to avoid conflict with new Iterable.isEmpty() method ! src/windows/classes/sun/nio/fs/WindowsPath.java From robert.field at oracle.com Fri Oct 7 15:09:25 2011 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 07 Oct 2011 22:09:25 +0000 Subject: hg: lambda/defender-prototype: Add enclosing method information. Improve error recovery, documentation, diagnostics. Message-ID: <20111007220925.337F747CD5@hg.openjdk.java.net> Changeset: 4fd91446f336 Author: Robert Field Date: 2011-10-07 15:09 -0700 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/4fd91446f336 Add enclosing method information. Improve error recovery, documentation, diagnostics. ! nbproject/project.xml ! src/jsr335/agent/Agent.java ! src/jsr335/agent/ClassModel.java ! src/jsr335/agent/ComputeWeaves.java ! src/jsr335/agent/MappingVisitor.java ! src/jsr335/agent/WeaveClassVisitor.java ! src/jsr335/agent/generic/ClassDType.java ! src/jsr335/agent/generic/DTypeVariable.java ! src/jsr335/agent/generic/TypeVariableMap.java From robert.field at oracle.com Fri Oct 7 16:44:31 2011 From: robert.field at oracle.com (robert.field at oracle.com) Date: Fri, 07 Oct 2011 23:44:31 +0000 Subject: hg: lambda/defender-prototype: prevent warnings in JDK builds for missing Woven annotation, by only generating when testing Message-ID: <20111007234431.4A2B547CE0@hg.openjdk.java.net> Changeset: ce7f71a7d0f5 Author: Robert Field Date: 2011-10-07 16:44 -0700 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/ce7f71a7d0f5 prevent warnings in JDK builds for missing Woven annotation, by only generating when testing ! build.xml ! src/jsr335/agent/Agent.java ! src/jsr335/agent/batch/Main.java From robert.field at oracle.com Fri Oct 7 23:29:16 2011 From: robert.field at oracle.com (robert.field at oracle.com) Date: Sat, 08 Oct 2011 06:29:16 +0000 Subject: hg: lambda/defender-prototype: 4 new changesets Message-ID: <20111008062917.0777E47D05@hg.openjdk.java.net> Changeset: 67cd1539520c Author: Robert Field Date: 2011-10-07 17:18 -0700 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/67cd1539520c Add InnerSuperTest. Improve test run diagnostics ! build.xml ! src/jsr335/agent/Agent.java ! src/jsr335/agent/batch/Main.java ! src/jsr335/agent/generic/DTypeVariable.java ! test/jsr335/agent/testng/InnerGenericTest.java Changeset: 41b7d71ce52b Author: Robert Field Date: 2011-10-07 17:28 -0700 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/41b7d71ce52b Add Test annotation ! test/jsr335/agent/testng/InnerGenericTest.java Changeset: 3ed77429430e Author: Robert Field Date: 2011-10-07 17:29 -0700 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/3ed77429430e Actually add InnerSuperTest + test/jsr335/agent/testng/InnerSuperTest.java Changeset: d911d32f33ef Author: Robert Field Date: 2011-10-07 23:29 -0700 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/d911d32f33ef Fix local class error. Remaining outer class issue, test added. Improve diagnostics ! src/jsr335/agent/ComputeWeaves.java ! src/jsr335/agent/WeaveClassVisitor.java ! src/jsr335/agent/batch/Main.java ! src/jsr335/agent/generic/ClassDType.java ! src/jsr335/agent/generic/TypeVariableMap.java + test/jsr335/agent/testng/InnerInterfaceTest.java From robert.field at oracle.com Sat Oct 8 18:40:40 2011 From: robert.field at oracle.com (robert.field at oracle.com) Date: Sun, 09 Oct 2011 01:40:40 +0000 Subject: hg: lambda/defender-prototype: Fixes JDK build. Mapping of default generic signature to defender generic signature. Message-ID: <20111009014040.EECC247D6A@hg.openjdk.java.net> Changeset: cafb48fb8da6 Author: Robert Field Date: 2011-10-08 18:40 -0700 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/cafb48fb8da6 Fixes JDK build. Mapping of default generic signature to defender generic signature. ! src/jsr335/agent/ClassModel.java ! src/jsr335/agent/ComputeWeaves.java ! src/jsr335/agent/Method.java ! src/jsr335/agent/ProjectedMethod.java ! src/jsr335/agent/RawMethod.java ! src/jsr335/agent/Weave.java ! src/jsr335/agent/batch/Main.java ! src/jsr335/agent/generic/ArrayDType.java ! src/jsr335/agent/generic/ClassDType.java ! src/jsr335/agent/generic/ClassDescriptor.java ! src/jsr335/agent/generic/DType.java ! src/jsr335/agent/generic/DTypeVariable.java ! src/jsr335/agent/generic/MethodDescriptor.java ! src/jsr335/agent/generic/PrimitiveDType.java ! src/jsr335/agent/generic/TypeVariableMap.java ! src/jsr335/agent/generic/WildCardMinusDType.java ! src/jsr335/agent/generic/WildCardPlusDType.java ! src/jsr335/agent/generic/WildCardStarDType.java From brian.goetz at oracle.com Mon Oct 10 08:06:52 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 10 Oct 2011 15:06:52 +0000 Subject: hg: lambda/defender-prototype: Update lambda syntax in ConvariantOverrideTest Message-ID: <20111010150653.1D7CA47E57@hg.openjdk.java.net> Changeset: b9ca75524985 Author: briangoetz Date: 2011-10-10 11:06 -0400 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/b9ca75524985 Update lambda syntax in ConvariantOverrideTest ! test/jsr335/agent/testng/CovariantOverrideTest.java From robert.field at oracle.com Mon Oct 10 15:30:15 2011 From: robert.field at oracle.com (robert.field at oracle.com) Date: Mon, 10 Oct 2011 22:30:15 +0000 Subject: hg: lambda/defender-prototype: 2 new changesets Message-ID: <20111010223015.A577F47EB2@hg.openjdk.java.net> Changeset: 9d46990b98b8 Author: Robert Field Date: 2011-10-10 15:28 -0700 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/9d46990b98b8 Handle subclassing of nested parameterized types. Fixes test failure. Additional test added. ! src/jsr335/agent/ComputeWeaves.java ! src/jsr335/agent/generic/ClassDType.java ! src/jsr335/agent/generic/DTypeVariable.java + test/jsr335/agent/testng/IndirectInnerInterfaceTest.java Changeset: f323874bba10 Author: Robert Field Date: 2011-10-10 15:30 -0700 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/f323874bba10 With merge: Handle subclassing of nested parameterized types. Fixes test failure. Additional test added. From brian.goetz at oracle.com Fri Oct 14 10:10:53 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Fri, 14 Oct 2011 17:10:53 +0000 Subject: hg: lambda/lambda/jdk: 4 new changesets Message-ID: <20111014171206.768DA48000@hg.openjdk.java.net> Changeset: 959009ef255d Author: briangoetz Date: 2011-09-27 17:30 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/959009ef255d Add specialized versions of Mapper: IntMapper, LongMapper, DoubleMapper ! make/java/java/FILES_java.gmk + src/share/classes/java/util/functions/DoubleMapper.java + src/share/classes/java/util/functions/IntMapper.java + src/share/classes/java/util/functions/LongMapper.java Changeset: a8b9ac600f7b Author: briangoetz Date: 2011-10-06 16:48 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a8b9ac600f7b Incremental work on bulk aggregate operations on Iterable -- filter, map, forEach, reduce, fused mapReduce for primitive specializations, into, {any,all,none}Match, sorted, uniqueElements; unit tests at Iterators, Iterables, and extension method levels for these; move Iterables to java.util; factories for comparators in Comparators; sort() methods in List; retrofit Fillable interface onto Collections ! make/java/java/FILES_java.gmk ! src/share/classes/java/lang/Iterable.java - src/share/classes/java/lang/Iterables.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/CollectionHelpers.java ! src/share/classes/java/util/Comparator.java + src/share/classes/java/util/Comparators.java + src/share/classes/java/util/Fillable.java + src/share/classes/java/util/Iterables.java ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/functions/Blocks.java + src/share/classes/java/util/functions/DoubleDoubleReducer.java + src/share/classes/java/util/functions/IntIntReducer.java + src/share/classes/java/util/functions/LongLongReducer.java + test-ng/build.xml + test-ng/tests/java/util/ComparatorsTest.java + test-ng/tests/java/util/IterableTest.java + test-ng/tests/java/util/IterablesTest.java + test-ng/tests/java/util/IteratorsNullTest.java + test-ng/tests/java/util/IteratorsTest.java + test-ng/tests/java/util/LambdaTestHelpers.java + test-ng/tests/java/util/NullArgsTestCase.java ! test/java/util/Iterators/LambdasTests.java Changeset: 939f695f9500 Author: briangoetz Date: 2011-10-14 12:35 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/939f695f9500 Rename Reducer and friends to Operator; modify Iterable.reduce and friends to use Operator ! .hgignore ! make/java/java/FILES_java.gmk ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/util/Iterables.java ! src/share/classes/java/util/Iterators.java - src/share/classes/java/util/functions/DoubleDoubleReducer.java + src/share/classes/java/util/functions/DoubleOperator.java - src/share/classes/java/util/functions/IntIntReducer.java + src/share/classes/java/util/functions/IntOperator.java - src/share/classes/java/util/functions/LongLongReducer.java + src/share/classes/java/util/functions/LongOperator.java + src/share/classes/java/util/functions/Operator.java - src/share/classes/java/util/functions/Reducer.java - src/share/classes/java/util/functions/Reducers.java ! test-ng/tests/java/util/IteratorsNullTest.java ! test-ng/tests/java/util/LambdaTestHelpers.java ! test/java/lang/Iterables/LambdasTests.java - test/java/util/functions/Reducer/ReducersTest.java Changeset: 047ebb137a95 Author: briangoetz Date: 2011-10-14 13:09 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/047ebb137a95 Merge From brian.goetz at oracle.com Mon Oct 17 12:22:13 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Mon, 17 Oct 2011 19:22:13 +0000 Subject: hg: lambda/lambda/jdk: Add ParallelIterable interface; add partial implementation in ParallelIterables; ParallelIterable wrapper for arrays Arrays.parallel(array); utility combinators for Comparators; partial test case for ParallelIterable Message-ID: <20111017192254.6532B47027@hg.openjdk.java.net> Changeset: db1dfef09cce Author: briangoetz Date: 2011-10-17 15:21 -0400 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/db1dfef09cce Add ParallelIterable interface; add partial implementation in ParallelIterables; ParallelIterable wrapper for arrays Arrays.parallel(array); utility combinators for Comparators; partial test case for ParallelIterable ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Comparator.java ! src/share/classes/java/util/Comparators.java ! src/share/classes/java/util/Iterables.java + src/share/classes/java/util/ParallelIterable.java + src/share/classes/java/util/ParallelIterables.java + src/share/classes/java/util/Splittable.java ! test-ng/tests/java/util/IterableTest.java ! test-ng/tests/java/util/LambdaTestHelpers.java + test-ng/tests/java/util/ParallelIterableTest.java From pbenedict at apache.org Mon Oct 17 12:29:22 2011 From: pbenedict at apache.org (Paul Benedict) Date: Mon, 17 Oct 2011 14:29:22 -0500 Subject: hg: lambda/lambda/jdk: Add ParallelIterable interface; add partial implementation in ParallelIterables; ParallelIterable wrapper for arrays Arrays.parallel(array); utility combinators for Comparators; partial test case for ParallelIterable In-Reply-To: <20111017192254.6532B47027@hg.openjdk.java.net> References: <20111017192254.6532B47027@hg.openjdk.java.net> Message-ID: Brian, I believe ArrrayIterator.next() needs to catch IIOBE and translate it to NoSuchElementException because that's the documented exception of next() Paul On Mon, Oct 17, 2011 at 2:22 PM, wrote: > Changeset: db1dfef09cce > Author: ? ?briangoetz > Date: ? ? ?2011-10-17 15:21 -0400 > URL: ? ? ? http://hg.openjdk.java.net/lambda/lambda/jdk/rev/db1dfef09cce > > Add ParallelIterable interface; add partial implementation in ParallelIterables; ParallelIterable wrapper for arrays Arrays.parallel(array); utility combinators for Comparators; partial test case for ParallelIterable > > ! make/java/java/FILES_java.gmk > ! src/share/classes/java/util/Arrays.java > ! src/share/classes/java/util/Comparator.java > ! src/share/classes/java/util/Comparators.java > ! src/share/classes/java/util/Iterables.java > + src/share/classes/java/util/ParallelIterable.java > + src/share/classes/java/util/ParallelIterables.java > + src/share/classes/java/util/Splittable.java > ! test-ng/tests/java/util/IterableTest.java > ! test-ng/tests/java/util/LambdaTestHelpers.java > + test-ng/tests/java/util/ParallelIterableTest.java > > > From brian.goetz at oracle.com Mon Oct 17 12:34:21 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 17 Oct 2011 15:34:21 -0400 Subject: hg: lambda/lambda/jdk: Add ParallelIterable interface; add partial implementation in ParallelIterables; ParallelIterable wrapper for arrays Arrays.parallel(array); utility combinators for Comparators; partial test case for ParallelIterable In-Reply-To: References: <20111017192254.6532B47027@hg.openjdk.java.net> Message-ID: <4E9C833D.9070906@oracle.com> Good catch, thanks. Though a better approach would probably be to fail fast in the constructor if the end index is inconsistent with the array length. Just to be clear, at this point this work is a total out-of-a-hat exploration, to see if the approach works. The code quality is entirely amateurish, intentionally; if the API approach doesn't work, there's no point in wasting time making the implementation better. On 10/17/2011 3:29 PM, Paul Benedict wrote: > Brian, > > I believe ArrrayIterator.next() needs to catch IIOBE and translate it > to NoSuchElementException because that's the documented exception of > next() > > Paul > > On Mon, Oct 17, 2011 at 2:22 PM, wrote: >> Changeset: db1dfef09cce >> Author: briangoetz >> Date: 2011-10-17 15:21 -0400 >> URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/db1dfef09cce >> >> Add ParallelIterable interface; add partial implementation in ParallelIterables; ParallelIterable wrapper for arrays Arrays.parallel(array); utility combinators for Comparators; partial test case for ParallelIterable >> >> ! make/java/java/FILES_java.gmk >> ! src/share/classes/java/util/Arrays.java >> ! src/share/classes/java/util/Comparator.java >> ! src/share/classes/java/util/Comparators.java >> ! src/share/classes/java/util/Iterables.java >> + src/share/classes/java/util/ParallelIterable.java >> + src/share/classes/java/util/ParallelIterables.java >> + src/share/classes/java/util/Splittable.java >> ! test-ng/tests/java/util/IterableTest.java >> ! test-ng/tests/java/util/LambdaTestHelpers.java >> + test-ng/tests/java/util/ParallelIterableTest.java >> >> >> From kasperni at gmail.com Mon Oct 17 14:39:10 2011 From: kasperni at gmail.com (Kasper Nielsen) Date: Mon, 17 Oct 2011 23:39:10 +0200 Subject: hg: lambda/lambda/jdk: Add ParallelIterable interface; add partial implementation in ParallelIterables; ParallelIterable wrapper for arrays Arrays.parallel(array); utility combinators for Comparators; partial test case for ParallelIterable In-Reply-To: <20111017192254.6532B47027@hg.openjdk.java.net> References: <20111017192254.6532B47027@hg.openjdk.java.net> Message-ID: <4E9CA07E.6050505@gmail.com> On 17-10-2011 21:22, brian.goetz at oracle.com wrote: > Changeset: db1dfef09cce > Author: briangoetz > Date: 2011-10-17 15:21 -0400 > URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/db1dfef09cce > > Add ParallelIterable interface; add partial implementation in ParallelIterables; ParallelIterable wrapper for arrays Arrays.parallel(array); utility combinators for Comparators; partial test case for ParallelIterable > > ! make/java/java/FILES_java.gmk > ! src/share/classes/java/util/Arrays.java > ! src/share/classes/java/util/Comparator.java > ! src/share/classes/java/util/Comparators.java > ! src/share/classes/java/util/Iterables.java > + src/share/classes/java/util/ParallelIterable.java > + src/share/classes/java/util/ParallelIterables.java > + src/share/classes/java/util/Splittable.java > ! test-ng/tests/java/util/IterableTest.java > ! test-ng/tests/java/util/LambdaTestHelpers.java > + test-ng/tests/java/util/ParallelIterableTest.java > > Hi, I don't know to what extent ParallelIterable is lazy evaluated but anyMatch = !filter().isEmpty(); noneMatch = filter().isEmpty(); On the other hand, maybe that is too much to ask of users. Cheers Kasper From dmitry.bessonov at oracle.com Tue Oct 18 12:08:33 2011 From: dmitry.bessonov at oracle.com (dmitry.bessonov at oracle.com) Date: Tue, 18 Oct 2011 12:08:33 -0700 (PDT) Subject: Auto Reply: lambda-dev Digest, Vol 23, Issue 12 Message-ID: <9659ae3a-59fa-4766-a38e-408022762475@default> Hello, I will be on vacation starting from Tuesday October 18th till Tuesday November the 1st, returning to the office on Wednesday the 2nd of November. Please contact Paul Rank or Alexey Fedorov for any AWT/Swing/Client issues. Please contact my manager Pavel Klodin regarding general questions. I will be offline. For extremely important cases I'll have (sms-preferred) phone: +7 921 949 95 14. Thank you, Dmitry From mike.duigou at oracle.com Wed Oct 19 10:18:03 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 19 Oct 2011 17:18:03 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20111019171839.CE6D04708D@hg.openjdk.java.net> Changeset: 7e737171a26f Author: mduigou Date: 2011-10-19 10:08 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7e737171a26f Adds the ability to disable building of demos and samples by defining environment variables NO_DEMOS and NO_SAMPLES. You must build samples and demos at least once as the image building step still requires the samples and demos to be present. ! make/Makefile ! make/common/shared/Sanity-Settings.gmk Changeset: ad5ef7e3b583 Author: mduigou Date: 2011-10-19 10:16 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ad5ef7e3b583 Merge From mike.duigou at oracle.com Thu Oct 20 18:08:59 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 21 Oct 2011 01:08:59 +0000 Subject: hg: lambda/lambda/jdk: Add TestNG tests to netbeans project. Add a little explanatory README to test-ng directory. Message-ID: <20111021010928.B2587470B9@hg.openjdk.java.net> Changeset: 27e3c5fb341f Author: mduigou Date: 2011-10-20 18:08 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/27e3c5fb341f Add TestNG tests to netbeans project. Add a little explanatory README to test-ng directory. ! make/netbeans/README ! make/netbeans/awt2d/nbproject/project.xml ! make/netbeans/common/README-ent + make/netbeans/common/testng-sources.ent + make/netbeans/common/testng-view.ent ! make/netbeans/j2se/nbproject/project.xml ! make/netbeans/jarzip/nbproject/project.xml ! make/netbeans/jconsole/nbproject/project.xml ! make/netbeans/jmx/nbproject/project.xml + test-ng/README ! test-ng/build.xml From mike.duigou at oracle.com Fri Oct 21 09:34:53 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 21 Oct 2011 16:34:53 +0000 Subject: hg: lambda/defender-prototype: ignore doc and lib dirs Message-ID: <20111021163454.2C5DC470C8@hg.openjdk.java.net> Changeset: 583bb853ea46 Author: mduigou Date: 2011-10-21 09:33 -0700 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/583bb853ea46 ignore doc and lib dirs ! .hgignore From mike.duigou at oracle.com Fri Oct 21 12:40:18 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 21 Oct 2011 19:40:18 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20111021194054.F125C470CA@hg.openjdk.java.net> Changeset: b91dc41f7ee0 Author: mduigou Date: 2011-10-21 12:38 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/b91dc41f7ee0 ignore test-ng lib directory ! .hgignore Changeset: ce9dee830c61 Author: mduigou Date: 2011-10-21 12:39 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ce9dee830c61 add TestNG tests as a compilation unit. ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent From mike.duigou at oracle.com Fri Oct 21 15:37:49 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 21 Oct 2011 22:37:49 +0000 Subject: hg: lambda/lambda/jdk: javadoc and minor corrections. Message-ID: <20111021223809.A6686470CD@hg.openjdk.java.net> Changeset: 630423acd924 Author: mduigou Date: 2011-10-21 15:37 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/630423acd924 javadoc and minor corrections. ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Fillable.java ! src/share/classes/java/util/ParallelIterables.java ! src/share/classes/java/util/Splittable.java ! test-ng/tests/java/util/ParallelIterableTest.java From scolebourne at joda.org Tue Oct 25 09:26:45 2011 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 25 Oct 2011 17:26:45 +0100 Subject: Syntax for method references Message-ID: Is this now decided? Or just an experiment? http://www.ibm.com/developerworks/java/library/j-ldn3/index.html?ca=drs- Collections.sortBy(people, Person::getLastName); people.sortBy(Person::getLastName); Stephen From mike.duigou at oracle.com Tue Oct 25 10:50:07 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Tue, 25 Oct 2011 17:50:07 +0000 Subject: hg: lambda/lambda/jdk: 3 new changesets Message-ID: <20111025175112.E069547116@hg.openjdk.java.net> Changeset: 6b4b6ae2f1c5 Author: mduigou Date: 2011-10-24 15:56 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/6b4b6ae2f1c5 javadoc fix ! src/share/classes/java/util/ParallelIterables.java Changeset: 7e01cd0091b6 Author: mduigou Date: 2011-10-24 15:57 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7e01cd0091b6 javadoc fixes ! src/share/classes/java/util/functions/Operator.java Changeset: ce289aa113eb Author: mduigou Date: 2011-10-25 10:32 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/ce289aa113eb converted versions of Blocks, Mappers, Predicates + test-ng/tests/java/util/functions/BlocksTest.java + test-ng/tests/java/util/functions/MappersTest.java + test-ng/tests/java/util/functions/PredicatesTest.java From brian.goetz at oracle.com Tue Oct 25 15:01:21 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 25 Oct 2011 15:01:21 -0700 Subject: Syntax for method references In-Reply-To: References: Message-ID: <3A749505-C59B-4247-AFD9-548ABD5484F9@oracle.com> This is the current front-runner. On Oct 25, 2011, at 9:26 AM, Stephen Colebourne wrote: > Is this now decided? Or just an experiment? > http://www.ibm.com/developerworks/java/library/j-ldn3/index.html?ca=drs- > > Collections.sortBy(people, Person::getLastName); > people.sortBy(Person::getLastName); > > Stephen > From maurizio.cimadamore at oracle.com Wed Oct 26 08:43:47 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 26 Oct 2011 15:43:47 +0000 Subject: hg: lambda/lambda/langtools: Updated compiler implementation as per latest spec draft (v0.4.1) Message-ID: <20111026154352.EFC944712D@hg.openjdk.java.net> Changeset: afd33b3093d3 Author: mcimadamore Date: 2011-10-26 16:41 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/afd33b3093d3 Updated compiler implementation as per latest spec draft (v0.4.1) *) Lambda parameters are not allowed to shadow locals in the enclosing scope anymore. Cleanup/improvements *) Simplified logic for lambda attribution environment creation in Attr.java *) Removed redundant flags in Flags.java *) Simplified lambda AST node *) Convert LambdaToInnerTranslator to a 'true' lambda/reference to inner class translator - i.e. so that it does not use ProxyHelper for method reference translation *) Removed '-XDuseIndy'/'-XDuseProxy' options - now indy is the default choice when -XDlambdaToMethod is selected *) Move code shared by both translators in the base class LambdaTranslator - now both translator share the same two-phase translation strategy (one step for analyzing lambdas/mrefs, one step for actual translation) *) Cleanup Gen.java (all method references are now completely desugared when we get to code generation - no need to support bytecode translation for method references) ! src/share/classes/com/sun/runtime/ProxyHelper.java ! src/share/classes/com/sun/tools/javac/code/Flags.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/Flow.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToInnerClass.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/LambdaTranslator.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/Gen.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! test/tools/javac/lambda/BadBreakContinue.out ! test/tools/javac/lambda/BadStatementInLambda02.out ! test/tools/javac/lambda/LambdaCapture01.java ! test/tools/javac/lambda/LambdaCapture02.java ! test/tools/javac/lambda/LambdaCapture03.java ! test/tools/javac/lambda/LambdaConv01.java ! test/tools/javac/lambda/LambdaScope01.java + test/tools/javac/lambda/LambdaScope04.java + test/tools/javac/lambda/LambdaScope04.out + test/tools/javac/lambda/MethodReference30.java ! test/tools/javac/lambda/sqe/lambdaExpression/LambdaTest4.java ! test/tools/javac/lambda/sqe/methodReference/BridgeMethod.java From mike.duigou at oracle.com Wed Oct 26 09:34:48 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 26 Oct 2011 16:34:48 +0000 Subject: hg: lambda/lambda/jdk: nits and javadoc. Message-ID: <20111026163528.A9B8047134@hg.openjdk.java.net> Changeset: 38dba9d15bf0 Author: mduigou Date: 2011-10-26 09:34 -0700 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/38dba9d15bf0 nits and javadoc. ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/util/Iterables.java ! src/share/classes/java/util/Iterators.java ! src/share/classes/java/util/ParallelIterables.java ! src/share/classes/java/util/Splittable.java From bobfoster at gmail.com Wed Oct 26 12:17:04 2011 From: bobfoster at gmail.com (Bob Foster) Date: Wed, 26 Oct 2011 12:17:04 -0700 Subject: Syntax for method references Message-ID: On Tue, 25 Oct 2011 15:01:21 -0700 (whew!) Brian Goetz wrote: Oh, good. The dreaded :: from C++. :) Bob > This is the current front-runner. > On Oct 25, 2011, at 9:26 AM, Stephen Colebourne wrote: >> Is this now decided? Or just an experiment? >> http://www.ibm.com/developerworks/java/library/j-ldn3/index.html?ca=drs- >> >> Collections.sortBy(people, Person::getLastName); >> people.sortBy(Person::getLastName); >> >> Stephen >> From serge.boulay at gmail.com Wed Oct 26 12:39:13 2011 From: serge.boulay at gmail.com (Serge Boulay) Date: Wed, 26 Oct 2011 15:39:13 -0400 Subject: Syntax for method references In-Reply-To: References: Message-ID: I liked the syntax shown at the 2011 JVM language summit Predicate<> p = String->isEmpty http://www.wiki.jvmlangsummit.com/images/a/a1/2011_Goetz_Extension_Slides.pdf On Wed, Oct 26, 2011 at 3:17 PM, Bob Foster wrote: > On Tue, 25 Oct 2011 15:01:21 -0700 (whew!) Brian Goetz wrote: > > Oh, good. The dreaded :: from C++. :) > > Bob > > > This is the current front-runner. > > > On Oct 25, 2011, at 9:26 AM, Stephen Colebourne wrote: > >> Is this now decided? Or just an experiment? > >> > http://www.ibm.com/developerworks/java/library/j-ldn3/index.html?ca=drs- > >> > >> Collections.sortBy(people, Person::getLastName); > >> people.sortBy(Person::getLastName); > >> > >> Stephen > >> > > From brian.goetz at oracle.com Wed Oct 26 13:38:47 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 26 Oct 2011 13:38:47 -0700 Subject: Syntax for method references In-Reply-To: References: Message-ID: It is perfect, until you realize it is unworkable; you need room for generic type arguments on both sides: foo->bar or foo->bar At which point you give up on that approach. On Oct 26, 2011, at 12:39 PM, Serge Boulay wrote: > I liked the syntax shown at the 2011 JVM language summit > > Predicate<> p = String->isEmpty > > http://www.wiki.jvmlangsummit.com/images/a/a1/2011_Goetz_Extension_Slides.pdf > > On Wed, Oct 26, 2011 at 3:17 PM, Bob Foster wrote: > >> On Tue, 25 Oct 2011 15:01:21 -0700 (whew!) Brian Goetz wrote: >> >> Oh, good. The dreaded :: from C++. :) >> >> Bob >> >>> This is the current front-runner. >> >>> On Oct 25, 2011, at 9:26 AM, Stephen Colebourne wrote: >>>> Is this now decided? Or just an experiment? >>>> >> http://www.ibm.com/developerworks/java/library/j-ldn3/index.html?ca=drs- >>>> >>>> Collections.sortBy(people, Person::getLastName); >>>> people.sortBy(Person::getLastName); >>>> >>>> Stephen >>>> >> >> > From collin.fagan at gmail.com Wed Oct 26 13:47:46 2011 From: collin.fagan at gmail.com (Collin Fagan) Date: Wed, 26 Oct 2011 15:47:46 -0500 Subject: Syntax for method references In-Reply-To: References: Message-ID: I think :: is just fine. I just wish there had been some announcement on the list that this was the front runner. Collin On Wed, Oct 26, 2011 at 3:38 PM, Brian Goetz wrote: > It is perfect, until you realize it is unworkable; you need room for > generic type arguments on both sides: > > foo->bar > > or > > foo->bar > > At which point you give up on that approach. > > > > On Oct 26, 2011, at 12:39 PM, Serge Boulay wrote: > > > I liked the syntax shown at the 2011 JVM language summit > > > > Predicate<> p = String->isEmpty > > > > > http://www.wiki.jvmlangsummit.com/images/a/a1/2011_Goetz_Extension_Slides.pdf > > > > On Wed, Oct 26, 2011 at 3:17 PM, Bob Foster wrote: > > > >> On Tue, 25 Oct 2011 15:01:21 -0700 (whew!) Brian Goetz wrote: > >> > >> Oh, good. The dreaded :: from C++. :) > >> > >> Bob > >> > >>> This is the current front-runner. > >> > >>> On Oct 25, 2011, at 9:26 AM, Stephen Colebourne wrote: > >>>> Is this now decided? Or just an experiment? > >>>> > >> > http://www.ibm.com/developerworks/java/library/j-ldn3/index.html?ca=drs- > >>>> > >>>> Collections.sortBy(people, Person::getLastName); > >>>> people.sortBy(Person::getLastName); > >>>> > >>>> Stephen > >>>> > >> > >> > > > > > From pbenedict at apache.org Wed Oct 26 13:52:51 2011 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 26 Oct 2011 15:52:51 -0500 Subject: Syntax for method references In-Reply-To: References: Message-ID: Will the justification be revealed for replacing # with double colon? I thought # had strong precedence due to Javadoc. I will find it interesting why the double colon won out. I also wonder if Javadoc could be updated based on this :-) Paul On Wed, Oct 26, 2011 at 3:47 PM, Collin Fagan wrote: > I think :: is just fine. I just wish there had been some announcement on > the > list that this was the front runner. > > Collin > > On Wed, Oct 26, 2011 at 3:38 PM, Brian Goetz > wrote: > > > It is perfect, until you realize it is unworkable; you need room for > > generic type arguments on both sides: > > > > foo->bar > > > > or > > > > foo->bar > > > > At which point you give up on that approach. > > > > > > > > On Oct 26, 2011, at 12:39 PM, Serge Boulay wrote: > > > > > I liked the syntax shown at the 2011 JVM language summit > > > > > > Predicate<> p = String->isEmpty > > > > > > > > > http://www.wiki.jvmlangsummit.com/images/a/a1/2011_Goetz_Extension_Slides.pdf > > > > > > On Wed, Oct 26, 2011 at 3:17 PM, Bob Foster > wrote: > > > > > >> On Tue, 25 Oct 2011 15:01:21 -0700 (whew!) Brian Goetz wrote: > > >> > > >> Oh, good. The dreaded :: from C++. :) > > >> > > >> Bob > > >> > > >>> This is the current front-runner. > > >> > > >>> On Oct 25, 2011, at 9:26 AM, Stephen Colebourne wrote: > > >>>> Is this now decided? Or just an experiment? > > >>>> > > >> > > http://www.ibm.com/developerworks/java/library/j-ldn3/index.html?ca=drs- > > >>>> > > >>>> Collections.sortBy(people, Person::getLastName); > > >>>> people.sortBy(Person::getLastName); > > >>>> > > >>>> Stephen > > >>>> > > >> > > >> > > > > > > > > > > > From brian.goetz at oracle.com Wed Oct 26 13:54:06 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 26 Oct 2011 13:54:06 -0700 Subject: Syntax for method references In-Reply-To: References: Message-ID: <90895A06-C9B7-42E9-9D65-F1F6486F9402@oracle.com> There was going to be an announcement when consensus was reached in the EG. We're not there yet; "front runner" is my subjective characterization based on recent discussions. We've been pretty consistent about relaying syntax decisions when they're made; this one isn't made yet. Note that this syntax was also shown in JavaOne presentations recently. Showing a candidate syntax in a conference presentation, blog post, or web article is one of the ways we gather feedback on ideas that are still being kicked around, since that gives us a chance to gauge reactions, which is one of the inputs we use in evaluating a syntax. (Keen observers might recall that each iteration of State of the Lambda used a *different* syntax for lambdas! And none of them were the final version.) On Oct 26, 2011, at 1:47 PM, Collin Fagan wrote: > I think :: is just fine. I just wish there had been some announcement on the list that this was the front runner. > > Collin > > On Wed, Oct 26, 2011 at 3:38 PM, Brian Goetz wrote: > It is perfect, until you realize it is unworkable; you need room for generic type arguments on both sides: > > foo->bar > > or > > foo->bar > > At which point you give up on that approach. > > > > On Oct 26, 2011, at 12:39 PM, Serge Boulay wrote: > > > I liked the syntax shown at the 2011 JVM language summit > > > > Predicate<> p = String->isEmpty > > > > http://www.wiki.jvmlangsummit.com/images/a/a1/2011_Goetz_Extension_Slides.pdf > > > > On Wed, Oct 26, 2011 at 3:17 PM, Bob Foster wrote: > > > >> On Tue, 25 Oct 2011 15:01:21 -0700 (whew!) Brian Goetz wrote: > >> > >> Oh, good. The dreaded :: from C++. :) > >> > >> Bob > >> > >>> This is the current front-runner. > >> > >>> On Oct 25, 2011, at 9:26 AM, Stephen Colebourne wrote: > >>>> Is this now decided? Or just an experiment? > >>>> > >> http://www.ibm.com/developerworks/java/library/j-ldn3/index.html?ca=drs- > >>>> > >>>> Collections.sortBy(people, Person::getLastName); > >>>> people.sortBy(Person::getLastName); > >>>> > >>>> Stephen > >>>> > >> > >> > > > > > From daniel.smith at oracle.com Wed Oct 26 15:48:13 2011 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 26 Oct 2011 15:48:13 -0700 Subject: Syntax for method references In-Reply-To: References: Message-ID: <771DF748-890A-455D-A811-F7AF12511C65@oracle.com> Even worse (or maybe just as bad -- I'm not immediately seeing the generic thing as catastrophic), it's ambiguous: x->y Is this a lambda expression or a method reference? ?Dan On Oct 26, 2011, at 1:38 PM, Brian Goetz wrote: > It is perfect, until you realize it is unworkable; you need room for generic type arguments on both sides: > > foo->bar > > or > > foo->bar > > At which point you give up on that approach. > > > > On Oct 26, 2011, at 12:39 PM, Serge Boulay wrote: > >> I liked the syntax shown at the 2011 JVM language summit >> >> Predicate<> p = String->isEmpty >> >> http://www.wiki.jvmlangsummit.com/images/a/a1/2011_Goetz_Extension_Slides.pdf >> >> On Wed, Oct 26, 2011 at 3:17 PM, Bob Foster wrote: >> >>> On Tue, 25 Oct 2011 15:01:21 -0700 (whew!) Brian Goetz wrote: >>> >>> Oh, good. The dreaded :: from C++. :) >>> >>> Bob >>> >>>> This is the current front-runner. >>> >>>> On Oct 25, 2011, at 9:26 AM, Stephen Colebourne wrote: >>>>> Is this now decided? Or just an experiment? >>>>> >>> http://www.ibm.com/developerworks/java/library/j-ldn3/index.html?ca=drs- >>>>> >>>>> Collections.sortBy(people, Person::getLastName); >>>>> people.sortBy(Person::getLastName); >>>>> >>>>> Stephen >>>>> >>> >>> >> > > From maurizio.cimadamore at oracle.com Thu Oct 27 08:42:41 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 27 Oct 2011 15:42:41 +0000 Subject: hg: lambda/lambda/langtools: Updated code generation strategy for extension methods: Message-ID: <20111027154248.BD0594716B@hg.openjdk.java.net> Changeset: 3721384cb546 Author: mcimadamore Date: 2011-10-27 16:41 +0100 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/3721384cb546 Updated code generation strategy for extension methods: *) Added compiler flag -XDinlinedExtensionBodies to generate code attribute for extension methods. The code attribute will contain an invokestatic to the default implementation. Enabling this flag disables generation of the Defender method attribute/annotation. *) Updated javap to correctly detect ACC_DEFENDER flag on interface methods ! src/share/classes/com/sun/tools/classfile/AccessFlags.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java + test/tools/javac/defender/TestInlinedDefenderBody.java From neal at gafter.com Thu Oct 27 10:46:20 2011 From: neal at gafter.com (Neal Gafter) Date: Thu, 27 Oct 2011 10:46:20 -0700 Subject: Syntax for method references In-Reply-To: <90895A06-C9B7-42E9-9D65-F1F6486F9402@oracle.com> References: <90895A06-C9B7-42E9-9D65-F1F6486F9402@oracle.com> Message-ID: On Wed, Oct 26, 2011 at 1:54 PM, Brian Goetz wrote: > There was going to be an announcement when consensus was reached in the EG. > We're not there yet; "front runner" is my subjective characterization based > on recent discussions. We've been pretty consistent about relaying syntax > decisions when they're made; this one isn't made yet. > Why should any announcement be necessary when the expert group discussions are public ? 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification. A publicly readable mailing list for expert group communication will be the primary working model. 2.15 Provide detailed answers to the transparency checklist, making sure to include URLs as appropriate: - The public can read the names of the people on the Expert Group. We intend this to be the case. - The Expert Group business is regularly reported on a publicly readable alias. We intend this to be the case. - The schedule for the JSR is publicly available, it's current, and I update it regularly. We intend this to be the case. - The public can read/write to a wiki for my JSR. Rather than a wiki which the Expert Group must take time out to visit, we intend to implement a pair of mailing lists following the approach of JSR 294 and JSR 330. First, Expert Group business will be carried out on a mailing list dedicated to Expert Group members. Second, an "observer" mailing list which anyone may join will receive the traffic of the Expert Group list. The observer list allows the public to follow Expert Group business, and is writable to allow the public to make comments for other observers to see and make further comment on. Expert Group members are under no obligation to join the observer list and partake in public discussion. In addition to these lists we will maintain a private Expert-Group-only list for administrative and other non-technical traffic. Cheers, Neal From bobfoster at gmail.com Thu Oct 27 19:39:23 2011 From: bobfoster at gmail.com (Bob Foster) Date: Thu, 27 Oct 2011 19:39:23 -0700 Subject: Syntax for method references Message-ID: On Thu, 27 Oct 2011 10:46:20 -0700 Neil Gafter wrote: From bobfoster at gmail.com Thu Oct 27 19:44:40 2011 From: bobfoster at gmail.com (Bob Foster) Date: Thu, 27 Oct 2011 19:44:40 -0700 Subject: Syntax for method references Message-ID: On Thu, 27 Oct 2011 10:46:20 -0700 Neil Gafter wrote: > Why should any announcement be necessary when the expert group > discussions are public ? > ... > Second, an "observer" > mailing list which anyone may join will receive the traffic of the Expert > Group list... Gosh, I didn't realize that. What is that mailing list? Would there be any risk of second-hand smoke in joining the list? Bob From sonali.goel at oracle.com Fri Oct 28 12:01:11 2011 From: sonali.goel at oracle.com (sonali.goel at oracle.com) Date: Fri, 28 Oct 2011 12:01:11 -0700 (PDT) Subject: Auto Reply: lambda-dev Digest, Vol 23, Issue 19 Message-ID: This is an auto-reply. I am out of office and will reply to emails when I get back on 11/01. For urgent matters, please contact Vita.Santrucek at oracle.com