From brian.goetz at oracle.com Thu Jan 5 16:35:38 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 05 Jan 2012 19:35:38 -0500 Subject: CFV: New Lambda committer: Stuart Marks Message-ID: <4F0641DA.6020402@oracle.com> I hereby nominate Stuart Marks to Lambda Committer. Stuart works in the Core Libraries team at Oracle, and has already contributed several change sets to the Lambda repository. Stuart will be contributing to the Lambdafication of existing library APIs. Stuart was previously involved in the API Coinification effort during the development of Java SE 7. Votes are due by January 19, 2012. Only current Lambda Committers [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. -Brian Goetz [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From david.holmes at oracle.com Thu Jan 5 17:38:48 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Jan 2012 11:38:48 +1000 Subject: CFV: New Lambda committer: Stuart Marks In-Reply-To: <4F0641DA.6020402@oracle.com> References: <4F0641DA.6020402@oracle.com> Message-ID: <4F0650A8.4080205@oracle.com> Vote: yes David ----- On 6/01/2012 10:35 AM, Brian Goetz wrote: > I hereby nominate Stuart Marks to Lambda Committer. > > Stuart works in the Core Libraries team at Oracle, and has already > contributed several change sets to the Lambda repository. Stuart will > be contributing to the Lambdafication of existing library APIs. Stuart > was previously involved in the API Coinification effort during the > development of Java SE 7. > > Votes are due by January 19, 2012. > > Only current Lambda Committers [1] are eligible to vote on > this nomination. > > For Lazy Consensus voting instructions, see [2]. > > -Brian Goetz > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From Robert.Field at oracle.com Thu Jan 5 19:25:54 2012 From: Robert.Field at oracle.com (Robert Field) Date: Thu, 05 Jan 2012 19:25:54 -0800 Subject: CFV: New Lambda committer: Stuart Marks In-Reply-To: <4F0641DA.6020402@oracle.com> References: <4F0641DA.6020402@oracle.com> Message-ID: <4F0669C2.3020902@oracle.com> Vote: Yes On 1/5/12 4:35 PM, Brian Goetz wrote: > I hereby nominate Stuart Marks to Lambda Committer. > > Stuart works in the Core Libraries team at Oracle, and has already > contributed several change sets to the Lambda repository. Stuart will > be contributing to the Lambdafication of existing library APIs. Stuart > was previously involved in the API Coinification effort during the > development of Java SE 7. > > Votes are due by January 19, 2012. > > Only current Lambda Committers [1] are eligible to vote on > this nomination. > > For Lazy Consensus voting instructions, see [2]. > > -Brian Goetz > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From forax at univ-mlv.fr Thu Jan 5 23:35:26 2012 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 06 Jan 2012 08:35:26 +0100 Subject: CFV: New Lambda committer: Stuart Marks Message-ID: <06ls685ek6kc66da70b0xebt.1325835326613@email.android.com> Vote yes. Remi Brian Goetz wrote: >I hereby nominate Stuart Marks to Lambda Committer. > >Stuart works in the Core Libraries team at Oracle, and has already >contributed several change sets to the Lambda repository. Stuart will >be contributing to the Lambdafication of existing library APIs. Stuart >was previously involved in the API Coinification effort during the >development of Java SE 7. > >Votes are due by January 19, 2012. > >Only current Lambda Committers [1] are eligible to vote on >this nomination. > >For Lazy Consensus voting instructions, see [2]. > >-Brian Goetz > > >[1] http://openjdk.java.net/census >[2] http://openjdk.java.net/projects/#committer-vote > From brian.goetz at oracle.com Fri Jan 6 16:15:12 2012 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Sat, 07 Jan 2012 00:15:12 +0000 Subject: hg: lambda/lambda/jdk: 2 new changesets Message-ID: <20120107001619.18F99478D9@hg.openjdk.java.net> Changeset: 7e592a11b492 Author: briangoetz Date: 2011-12-30 18:16 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/7e592a11b492 Remove questionable List, Block methods ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/List.java - src/share/classes/java/util/ListHelpers.java ! src/share/classes/java/util/functions/Block.java ! src/share/classes/java/util/functions/Blocks.java ! test-ng/tests/java/util/functions/BlocksTest.java Changeset: a1a106adff5f Author: briangoetz Date: 2012-01-06 19:14 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/a1a106adff5f Add Iterable.get{First,Any,Only}; make ParallelIterable.into actually parallel; add Iterable.cumulate ! 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/ParallelIterable.java ! src/share/classes/java/util/ParallelIterables.java ! test-ng/tests/java/util/IterableTest.java ! test-ng/tests/java/util/IterablesTest.java ! test-ng/tests/java/util/LambdaTestHelpers.java ! test-ng/tests/java/util/ParallelIterableTest.java From mike.duigou at oracle.com Fri Jan 6 23:21:21 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 6 Jan 2012 23:21:21 -0800 Subject: CFV: New Lambda committer: Stuart Marks In-Reply-To: <4F0641DA.6020402@oracle.com> References: <4F0641DA.6020402@oracle.com> Message-ID: <64855540-27F4-4D52-A9D1-C2E45EB86998@oracle.com> Vote: yes On Jan 5 2012, at 16:35 , Brian Goetz wrote: > I hereby nominate Stuart Marks to Lambda Committer. > > Stuart works in the Core Libraries team at Oracle, and has already > contributed several change sets to the Lambda repository. Stuart will > be contributing to the Lambdafication of existing library APIs. Stuart > was previously involved in the API Coinification effort during the > development of Java SE 7. > > Votes are due by January 19, 2012. > > Only current Lambda Committers [1] are eligible to vote on > this nomination. > > For Lazy Consensus voting instructions, see [2]. > > -Brian Goetz > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From reinier at zwitserloot.com Sat Jan 7 04:36:37 2012 From: reinier at zwitserloot.com (Reinier Zwitserloot) Date: Sat, 7 Jan 2012 13:36:37 +0100 Subject: Method reference conversion In-Reply-To: <4EEAFE60.6080706@univ-mlv.fr> References: <4EEA5A1D.8040700@gmail.com> <5F7D81B4-5363-4BF6-AC0D-3FF7A87AE94F@oracle.com> <4EEAF332.9070105@gmail.com> <4EEAFE60.6080706@univ-mlv.fr> Message-ID: A while ago we did some internal research on listeners, and removeListener was rarely getting called. As R?mi said, if you need to detach a listener in the somewhat classic 'addListener' / 'removeListener' setup, you need to store the ref you originally pass to 'addListener' somewhere so you can pass it again when the time comes to call 'removeListener'. However, this 'addListener'/'removeListener' is not actually a particularly nice API for registering temporary listeners. This gets particularly relevant when you run into the 'lapsed listener' problem. There are solutions to the lapsed listener problem, i.e. adding an 'owner object' of some sort which is carefully GC-managed via WeakReferences, and unregistering the listener when the owner object gets GCed, the details of which aren't relevant for lambda-dev. My point is: I don't think "may not play well with classic 'removeListener' methods" should not trump "makes future optimization potentially much more difficult than it needs to be because we make promises now that we'd rather not keep later", because removeListener itself is both rarely used and feels, at least to me, as an anti-pattern in the first place. --Reinier Zwitserloot On Fri, Dec 16, 2011 at 09:16, R?mi Forax wrote: > On 12/16/2011 08:28 AM, Uther wrote: > >> On Dec 15, 2011, at 4:10 PM, Brian Goetz wrote: > >> > >> Most likely outcome: no guarantees (such guarantees come with a cost) > but it > >> is "highly likely" that method1 == method2. When we finish the > implementation > >> of functional interface conversion we'll have a update. > > So Method reference are not really suited to Listeners. I think it's a > > shame since it was a really good use case of method reference. > > If you have to unregister a listener, you have to store the listener in > a field when you create it, > to be able to send the same reference when you unregister it. > > If two method reference bound to the same object share the same reference > you need to cache them somewhere, so you create a performance tax > everywhere you create a > method reference and it will never scale in a threaded environment. > > R?mi > > > From maurizio.cimadamore at oracle.com Sat Jan 7 06:57:56 2012 From: maurizio.cimadamore at oracle.com (maurizio cimadamore) Date: Sat, 07 Jan 2012 14:57:56 +0000 Subject: CFV: New Lambda committer: Stuart Marks In-Reply-To: <4F0641DA.6020402@oracle.com> References: <4F0641DA.6020402@oracle.com> Message-ID: <4F085D74.1020502@oracle.com> Vote: yes On 06-Jan-12 12:35 AM, Brian Goetz wrote: > I hereby nominate Stuart Marks to Lambda Committer. > > Stuart works in the Core Libraries team at Oracle, and has already > contributed several change sets to the Lambda repository. Stuart will > be contributing to the Lambdafication of existing library APIs. Stuart > was previously involved in the API Coinification effort during the > development of Java SE 7. > > Votes are due by January 19, 2012. > > Only current Lambda Committers [1] are eligible to vote on > this nomination. > > For Lazy Consensus voting instructions, see [2]. > > -Brian Goetz > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From isidore at setgame.com Sat Jan 7 11:02:21 2012 From: isidore at setgame.com (Llewellyn Falco) Date: Sat, 7 Jan 2012 11:02:21 -0800 Subject: Method reference conversion In-Reply-To: References: <4EEA5A1D.8040700@gmail.com> <5F7D81B4-5363-4BF6-AC0D-3FF7A87AE94F@oracle.com> <4EEAF332.9070105@gmail.com> <4EEAFE60.6080706@univ-mlv.fr> Message-ID: I'm not sure if you guy's are aware, but there has been some amazing working on this in the .net world by Erik Meijer, one of the creators of Haskell. http://msdn.microsoft.com/en-us/data/gg577609 I realize that it will be harder to create this type of fluid library in java, because of the lack of extension methods and the need to finalize internal variable, but even in reverse polish notion and goofy array wrappers, this is way to powerful not to show up soon after lambdas hit the scene. ..... on a side note I was just thinking that the array wrapping might be semi-nicely solved by a Mutable class as such public Class Mutable { public T _; public Mutable(T originalValue) { _ = originalValue; } } then you just end up with stuff like myVariable._ = 5; On Sat, Jan 7, 2012 at 4:36 AM, Reinier Zwitserloot wrote: > A while ago we did some internal research on listeners, and removeListener > was rarely getting called. As R?mi said, if you need to detach a listener > in the somewhat classic 'addListener' / 'removeListener' setup, you need to > store the ref you originally pass to 'addListener' somewhere so you can > pass it again when the time comes to call 'removeListener'. > > However, this 'addListener'/'removeListener' is not actually a particularly > nice API for registering temporary listeners. This gets particularly > relevant when you run into the 'lapsed listener' problem. There are > solutions to the lapsed listener problem, i.e. adding an 'owner object' of > some sort which is carefully GC-managed via WeakReferences, and > unregistering the listener when the owner object gets GCed, the details of > which aren't relevant for lambda-dev. > > My point is: I don't think "may not play well with classic 'removeListener' > methods" should not trump "makes future optimization potentially much more > difficult than it needs to be because we make promises now that we'd rather > not keep later", because removeListener itself is both rarely used and > feels, at least to me, as an anti-pattern in the first place. > > ?--Reinier Zwitserloot > > > > On Fri, Dec 16, 2011 at 09:16, R?mi Forax wrote: > >> On 12/16/2011 08:28 AM, Uther wrote: >> >> On Dec 15, 2011, at 4:10 PM, Brian Goetz wrote: >> >> >> >> Most likely outcome: no guarantees (such guarantees come with a cost) >> but it >> >> is "highly likely" that method1 == method2. When we finish the >> implementation >> >> of functional interface conversion we'll have a update. >> > So Method reference are not really suited to Listeners. I think it's a >> > shame since it was a really good use case of method reference. >> >> If you have to unregister a listener, you have to store the listener in >> a field when you create it, >> to be able to send the same reference when you unregister it. >> >> If two method reference bound to the same object share the same reference >> you need to cache them somewhere, so you create a performance tax >> everywhere you create a >> method reference and it will never scale in a threaded environment. >> >> R?mi >> >> >> > -- Llewellyn Falco www.approvaltests.com www.teachingkidsprogramming.org From bitterfoxc at gmail.com Mon Jan 9 01:41:29 2012 From: bitterfoxc at gmail.com (bitter_fox) Date: Mon, 9 Jan 2012 18:41:29 +0900 Subject: Javac throws AssertionError(Unexpected intersection type) for CompoundTypeGenerics Message-ID: Javac(Revision: 1245) throws AssertionError when I compile this program: import java.util.*; public class Test3 { interface Marker1 {} interface Marker2 {} static class Object1 implements Marker1, Marker2 {} static class Object2 implements Marker1, Marker2 {} interface SAM1 { RET invoke(ARG1 arg1); } public static void main(String[] args) { Test3.test(Arrays.asList(new Object1(), new Object2()), e -> e); } public static void test(Iterable iterable, SAM1 sam) {} } This is the StackTrace: java.lang.AssertionError: Unexpected intersection type: java.lang.Object&Main.M arker1&Main.Marker2 at com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:895) at com.sun.tools.javac.jvm.ClassWriter.assembleClassSig(ClassWriter.java :383) at com.sun.tools.javac.jvm.ClassWriter.assembleSig(ClassWriter.java:307) at com.sun.tools.javac.jvm.ClassWriter.assembleSig(ClassWriter.java:410) at com.sun.tools.javac.jvm.ClassWriter.assembleClassSig(ClassWriter.java :402) at com.sun.tools.javac.jvm.ClassWriter.assembleSig(ClassWriter.java:307) at com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1 592) at com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1506) at com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:728) at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1466 ) at com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1434 ) at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:885) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:844) at com.sun.tools.javac.main.Main.compile(Main.java:430) at com.sun.tools.javac.main.Main.compile(Main.java:344) at com.sun.tools.javac.main.Main.compile(Main.java:335) at com.sun.tools.javac.Main.compile(Main.java:76) at com.sun.tools.javac.Main.main(Main.java:61) Was this problem already known? Thank you, bitter_fox From keith.mcguigan at oracle.com Mon Jan 9 03:43:47 2012 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Mon, 9 Jan 2012 06:43:47 -0500 Subject: CFV: New Lambda committer: Stuart Marks In-Reply-To: <4F0641DA.6020402@oracle.com> References: <4F0641DA.6020402@oracle.com> Message-ID: <76E876BD-4F7D-4B46-931B-D2B736E7249D@oracle.com> Vote: yes On Jan 5, 2012, at 7:35 PM, Brian Goetz wrote: > I hereby nominate Stuart Marks to Lambda Committer. > > Stuart works in the Core Libraries team at Oracle, and has already > contributed several change sets to the Lambda repository. Stuart will > be contributing to the Lambdafication of existing library APIs. > Stuart > was previously involved in the API Coinification effort during the > development of Java SE 7. > > Votes are due by January 19, 2012. > > Only current Lambda Committers [1] are eligible to vote on > this nomination. > > For Lazy Consensus voting instructions, see [2]. > > -Brian Goetz > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From brian.goetz at oracle.com Mon Jan 9 08:46:21 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 09 Jan 2012 11:46:21 -0500 Subject: Result: New Lambda Committer: Stuart Marks Message-ID: <4F0B19DD.3060701@oracle.com> Voting for Stuart Marks [1] is now closed. Yes: 8 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -Brian Goetz [1] http://mail.openjdk.java.net/pipermail/lambda-dev/2012-January/004469.html From keith.mcguigan at oracle.com Mon Jan 9 12:46:19 2012 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Mon, 09 Jan 2012 20:46:19 +0000 Subject: hg: lambda/lambda/hotspot: [mq]: ext_methods Message-ID: <20120109204628.244DE478F4@hg.openjdk.java.net> Changeset: 691ef456ff6c Author: kamg Date: 2011-12-22 15:17 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/691ef456ff6c [mq]: ext_methods + 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/verifier.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/accessFlags.hpp ! src/share/vm/utilities/growableArray.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp + src/share/vm/utilities/resourceHash.hpp From stuart.marks at oracle.com Mon Jan 9 15:58:14 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 09 Jan 2012 15:58:14 -0800 Subject: Result: New Lambda Committer: Stuart Marks In-Reply-To: <4F0B19DD.3060701@oracle.com> References: <4F0B19DD.3060701@oracle.com> Message-ID: <4F0B7F16.2070200@oracle.com> Hey, great, thanks everybody, that was quick! Now to figure out how I shall use my newly acquired power. Bwahahaha! :-) s'marks On 1/9/12 8:46 AM, Brian Goetz wrote: > Voting for Stuart Marks [1] is now closed. > > Yes: 8 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Lazy Consensus, this is > sufficient to approve the nomination. > > -Brian Goetz > > [1] > http://mail.openjdk.java.net/pipermail/lambda-dev/2012-January/004469.html > From forax at univ-mlv.fr Tue Jan 10 00:14:58 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 10 Jan 2012 09:14:58 +0100 Subject: hg: lambda/lambda/hotspot: [mq]: ext_methods In-Reply-To: <20120109204628.244DE478F4@hg.openjdk.java.net> References: <20120109204628.244DE478F4@hg.openjdk.java.net> Message-ID: <4F0BF382.5030205@univ-mlv.fr> Hi Keith, That's a big patch ! Just a question about bytecodeAssembler, I know that the JSR 292 method handle implementation also generates bytecodes and it seems that the opcodes needed by bytecodeAssembler is a subset of the ones used by the JSR 292 implementation. It could be a good idea to try to reuse the same class for both generators. CC to John and Christian to see if it's a good idea. R?mi On 01/09/2012 09:46 PM, keith.mcguigan at oracle.com wrote: > Changeset: 691ef456ff6c > Author: kamg > Date: 2011-12-22 15:17 -0500 > URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/691ef456ff6c > > [mq]: ext_methods > > + 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/verifier.cpp > ! src/share/vm/interpreter/linkResolver.cpp > ! src/share/vm/interpreter/rewriter.cpp > ! src/share/vm/oops/instanceKlass.cpp > ! src/share/vm/oops/instanceKlass.hpp > ! src/share/vm/oops/instanceKlassKlass.cpp > ! src/share/vm/oops/klassVtable.cpp > ! src/share/vm/oops/klassVtable.hpp > ! src/share/vm/oops/methodOop.hpp > ! src/share/vm/prims/jvm.h > ! src/share/vm/runtime/globals.hpp > ! src/share/vm/utilities/accessFlags.hpp > ! src/share/vm/utilities/growableArray.hpp > ! src/share/vm/utilities/ostream.cpp > ! src/share/vm/utilities/ostream.hpp > + src/share/vm/utilities/resourceHash.hpp > > From keith.mcguigan at oracle.com Tue Jan 10 04:21:17 2012 From: keith.mcguigan at oracle.com (Keith McGuigan) Date: Tue, 10 Jan 2012 07:21:17 -0500 Subject: hg: lambda/lambda/hotspot: [mq]: ext_methods In-Reply-To: <4F0BF382.5030205@univ-mlv.fr> References: <20120109204628.244DE478F4@hg.openjdk.java.net> <4F0BF382.5030205@univ-mlv.fr> Message-ID: <83FCD826-678A-44EB-8F46-643D5C217C70@oracle.com> Can you point me towards the parts of the JSR 292 implementation that you think can be reused, and maybe a basic framework of what you're thinking of? I did look around a little but I didn't see any obvious way of reusing that code. -- - Keith On Jan 10, 2012, at 3:14 AM, R?mi Forax wrote: > Hi Keith, > That's a big patch ! > > Just a question about bytecodeAssembler, I know that the JSR 292 > method > handle > implementation also generates bytecodes and it seems that the > opcodes needed > by bytecodeAssembler is a subset of the ones used by the JSR 292 > implementation. > It could be a good idea to try to reuse the same class for both > generators. > > CC to John and Christian to see if it's a good idea. > > R?mi > > On 01/09/2012 09:46 PM, keith.mcguigan at oracle.com wrote: >> Changeset: 691ef456ff6c >> Author: kamg >> Date: 2011-12-22 15:17 -0500 >> URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/691ef456ff6c >> >> [mq]: ext_methods >> >> + 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/verifier.cpp >> ! src/share/vm/interpreter/linkResolver.cpp >> ! src/share/vm/interpreter/rewriter.cpp >> ! src/share/vm/oops/instanceKlass.cpp >> ! src/share/vm/oops/instanceKlass.hpp >> ! src/share/vm/oops/instanceKlassKlass.cpp >> ! src/share/vm/oops/klassVtable.cpp >> ! src/share/vm/oops/klassVtable.hpp >> ! src/share/vm/oops/methodOop.hpp >> ! src/share/vm/prims/jvm.h >> ! src/share/vm/runtime/globals.hpp >> ! src/share/vm/utilities/accessFlags.hpp >> ! src/share/vm/utilities/growableArray.hpp >> ! src/share/vm/utilities/ostream.cpp >> ! src/share/vm/utilities/ostream.hpp >> + src/share/vm/utilities/resourceHash.hpp >> >> > > From forax at univ-mlv.fr Tue Jan 10 04:44:49 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 10 Jan 2012 13:44:49 +0100 Subject: hg: lambda/lambda/hotspot: [mq]: ext_methods In-Reply-To: <83FCD826-678A-44EB-8F46-643D5C217C70@oracle.com> References: <20120109204628.244DE478F4@hg.openjdk.java.net> <4F0BF382.5030205@univ-mlv.fr> <83FCD826-678A-44EB-8F46-643D5C217C70@oracle.com> Message-ID: <4F0C32C1.9010105@univ-mlv.fr> On 01/10/2012 01:21 PM, Keith McGuigan wrote: > > Can you point me towards the parts of the JSR 292 implementation that > you think can be reused, and maybe a basic framework of what you're > thinking of? I did look around a little but I didn't see any obvious > way of reusing that code. > > -- > - Keith sure, look for MethodHandleCompiler in prims/methodHandleWalk.cpp. R?mi > > On Jan 10, 2012, at 3:14 AM, R?mi Forax wrote: > >> Hi Keith, >> That's a big patch ! >> >> Just a question about bytecodeAssembler, I know that the JSR 292 method >> handle >> implementation also generates bytecodes and it seems that the opcodes >> needed >> by bytecodeAssembler is a subset of the ones used by the JSR 292 >> implementation. >> It could be a good idea to try to reuse the same class for both >> generators. >> >> CC to John and Christian to see if it's a good idea. >> >> R?mi >> >> On 01/09/2012 09:46 PM, keith.mcguigan at oracle.com wrote: >>> Changeset: 691ef456ff6c >>> Author: kamg >>> Date: 2011-12-22 15:17 -0500 >>> URL: >>> http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/691ef456ff6c >>> >>> [mq]: ext_methods >>> >>> + 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/verifier.cpp >>> ! src/share/vm/interpreter/linkResolver.cpp >>> ! src/share/vm/interpreter/rewriter.cpp >>> ! src/share/vm/oops/instanceKlass.cpp >>> ! src/share/vm/oops/instanceKlass.hpp >>> ! src/share/vm/oops/instanceKlassKlass.cpp >>> ! src/share/vm/oops/klassVtable.cpp >>> ! src/share/vm/oops/klassVtable.hpp >>> ! src/share/vm/oops/methodOop.hpp >>> ! src/share/vm/prims/jvm.h >>> ! src/share/vm/runtime/globals.hpp >>> ! src/share/vm/utilities/accessFlags.hpp >>> ! src/share/vm/utilities/growableArray.hpp >>> ! src/share/vm/utilities/ostream.cpp >>> ! src/share/vm/utilities/ostream.hpp >>> + src/share/vm/utilities/resourceHash.hpp >>> >>> >> >> > From forax at univ-mlv.fr Tue Jan 10 05:02:53 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 10 Jan 2012 14:02:53 +0100 Subject: hg: lambda/lambda/hotspot: [mq]: ext_methods In-Reply-To: <1EC6406F-6135-4B35-8382-6F2B1A1C3EAF@oracle.com> References: <20120109204628.244DE478F4@hg.openjdk.java.net> <4F0BF382.5030205@univ-mlv.fr> <83FCD826-678A-44EB-8F46-643D5C217C70@oracle.com> <4F0C32C1.9010105@univ-mlv.fr> <1EC6406F-6135-4B35-8382-6F2B1A1C3EAF@oracle.com> Message-ID: <4F0C36FD.3060302@univ-mlv.fr> On 01/10/2012 01:55 PM, Christian Thalinger wrote: > On Jan 10, 2012, at 1:44 PM, R?mi Forax wrote: > >> On 01/10/2012 01:21 PM, Keith McGuigan wrote: >>> Can you point me towards the parts of the JSR 292 implementation that you think can be reused, and maybe a basic framework of what you're thinking of? I did look around a little but I didn't see any obvious way of reusing that code. >>> >>> -- >>> - Keith >> sure, >> look for MethodHandleCompiler in prims/methodHandleWalk.cpp. > I don't know what's the purpose of that assembler is but with our current JSR 292 work we will remove the MethodHandleWalker completely in the future. So don't use code *from* the MHW! Only the other way around ;-) > > -- Chris Ok, so Keith, sorry for the noise. R?mi From keith.mcguigan at oracle.com Tue Jan 10 07:23:11 2012 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Tue, 10 Jan 2012 15:23:11 +0000 Subject: hg: lambda/lambda/jdk: Summary: Sync jvm.h JVM_ACC_DEFAULT flag, prevent verification of overpass method Message-ID: <20120110152321.DB90447904@hg.openjdk.java.net> Changeset: 78684ee5be2c Author: kamg Date: 2012-01-10 10:06 -0500 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/78684ee5be2c Summary: Sync jvm.h JVM_ACC_DEFAULT flag, prevent verification of overpass method ! src/share/javavm/export/classfile_constants.h ! src/share/javavm/export/jvm.h ! src/share/native/common/check_code.c From maurizio.cimadamore at oracle.com Tue Jan 10 09:07:58 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 10 Jan 2012 17:07:58 +0000 Subject: hg: lambda/lambda/langtools: Code generation bug fixes: Message-ID: <20120110170807.7F32947906@hg.openjdk.java.net> Changeset: d916b00382ed Author: mcimadamore Date: 2012-01-10 16:16 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d916b00382ed Code generation bug fixes: *) Supertype of synthetic lambda classes is not erased *) Problems when creating inner class (with proper enclosing instance) inside a lambda expression ! 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 + test/tools/javac/lambda/LambdaExpr11.java + test/tools/javac/lambda/LambdaExpr12.java + test/tools/javac/lambda/TargetType35.java From maurizio.cimadamore at oracle.com Tue Jan 10 09:35:22 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 10 Jan 2012 17:35:22 +0000 Subject: Javac throws AssertionError(Unexpected intersection type) for CompoundTypeGenerics In-Reply-To: References: Message-ID: <4F0C76DA.9080004@oracle.com> Hi, this bug has been fixed in the latest push. Thanks for the report Maurizio On 09/01/12 09:41, bitter_fox wrote: > Javac(Revision: 1245) throws AssertionError when I compile this program: > > import java.util.*; > > public class Test3 > { > interface Marker1 > {} > > interface Marker2 > {} > > static class Object1 implements Marker1, Marker2 > {} > > static class Object2 implements Marker1, Marker2 > {} > > interface SAM1 > { > RET invoke(ARG1 arg1); > } > > public static void main(String[] args) > { > Test3.test(Arrays.asList(new Object1(), new Object2()), e -> e); > } > > public static void test(Iterable iterable, SAM1 sam) > {} > } > > This is the StackTrace: > > java.lang.AssertionError: Unexpected intersection type: > java.lang.Object&Main.M > arker1&Main.Marker2 > at > com.sun.tools.javac.jvm.ClassWriter.enterInner(ClassWriter.java:895) > at > com.sun.tools.javac.jvm.ClassWriter.assembleClassSig(ClassWriter.java > :383) > at > com.sun.tools.javac.jvm.ClassWriter.assembleSig(ClassWriter.java:307) > > at > com.sun.tools.javac.jvm.ClassWriter.assembleSig(ClassWriter.java:410) > > at > com.sun.tools.javac.jvm.ClassWriter.assembleClassSig(ClassWriter.java > :402) > at > com.sun.tools.javac.jvm.ClassWriter.assembleSig(ClassWriter.java:307) > > at > com.sun.tools.javac.jvm.ClassWriter.writeClassFile(ClassWriter.java:1 > 592) > at > com.sun.tools.javac.jvm.ClassWriter.writeClass(ClassWriter.java:1506) > > at > com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:728) > at > com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1466 > ) > at > com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1434 > ) > at > com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:885) > > at > com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:844) > at com.sun.tools.javac.main.Main.compile(Main.java:430) > at com.sun.tools.javac.main.Main.compile(Main.java:344) > at com.sun.tools.javac.main.Main.compile(Main.java:335) > at com.sun.tools.javac.Main.compile(Main.java:76) > at com.sun.tools.javac.Main.main(Main.java:61) > > Was this problem already known? > > Thank you, > bitter_fox > From brian.goetz at oracle.com Tue Jan 10 13:03:35 2012 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 10 Jan 2012 16:03:35 -0500 Subject: Extension method support in HotSpot Message-ID: <4F0CA7A7.3060308@oracle.com> Keith has pushed some changes to the lambda/hotspot repository that provide a preliminary implementation of extension methods in the VM. So far these are looking really good! Nice job Keith! We'll try and get a binary drop together soon so that people can try it out more easily. From robert.field at oracle.com Tue Jan 10 17:12:26 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Wed, 11 Jan 2012 01:12:26 +0000 Subject: hg: lambda/defender-prototype: add test target 'test-unwoven' Message-ID: <20120111011227.0B6D747912@hg.openjdk.java.net> Changeset: 22cb741160a3 Author: Robert Field Date: 2012-01-10 17:12 -0800 URL: http://hg.openjdk.java.net/lambda/defender-prototype/rev/22cb741160a3 add test target 'test-unwoven' ! build.xml From robert.field at oracle.com Tue Jan 10 17:51:56 2012 From: robert.field at oracle.com (robert.field at oracle.com) Date: Wed, 11 Jan 2012 01:51:56 +0000 Subject: hg: lambda/lambda/jdk: remove default method weaving from builds of the JDK Message-ID: <20120111015213.5767947915@hg.openjdk.java.net> Changeset: d96afa0fa487 Author: Robert Field Date: 2012-01-10 17:16 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/jdk/rev/d96afa0fa487 remove default method weaving from builds of the JDK ! make/common/Defs.gmk ! make/common/Release.gmk From christian.thalinger at oracle.com Tue Jan 10 04:55:41 2012 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 Jan 2012 13:55:41 +0100 Subject: hg: lambda/lambda/hotspot: [mq]: ext_methods In-Reply-To: <4F0C32C1.9010105@univ-mlv.fr> References: <20120109204628.244DE478F4@hg.openjdk.java.net> <4F0BF382.5030205@univ-mlv.fr> <83FCD826-678A-44EB-8F46-643D5C217C70@oracle.com> <4F0C32C1.9010105@univ-mlv.fr> Message-ID: <1EC6406F-6135-4B35-8382-6F2B1A1C3EAF@oracle.com> On Jan 10, 2012, at 1:44 PM, R?mi Forax wrote: > On 01/10/2012 01:21 PM, Keith McGuigan wrote: >> >> Can you point me towards the parts of the JSR 292 implementation that you think can be reused, and maybe a basic framework of what you're thinking of? I did look around a little but I didn't see any obvious way of reusing that code. >> >> -- >> - Keith > > sure, > look for MethodHandleCompiler in prims/methodHandleWalk.cpp. I don't know what's the purpose of that assembler is but with our current JSR 292 work we will remove the MethodHandleWalker completely in the future. So don't use code *from* the MHW! Only the other way around ;-) -- Chris > > R?mi > >> >> On Jan 10, 2012, at 3:14 AM, R?mi Forax wrote: >> >>> Hi Keith, >>> That's a big patch ! >>> >>> Just a question about bytecodeAssembler, I know that the JSR 292 method >>> handle >>> implementation also generates bytecodes and it seems that the opcodes needed >>> by bytecodeAssembler is a subset of the ones used by the JSR 292 >>> implementation. >>> It could be a good idea to try to reuse the same class for both generators. >>> >>> CC to John and Christian to see if it's a good idea. >>> >>> R?mi >>> >>> On 01/09/2012 09:46 PM, keith.mcguigan at oracle.com wrote: >>>> Changeset: 691ef456ff6c >>>> Author: kamg >>>> Date: 2011-12-22 15:17 -0500 >>>> URL: http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/691ef456ff6c >>>> >>>> [mq]: ext_methods >>>> >>>> + 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/verifier.cpp >>>> ! src/share/vm/interpreter/linkResolver.cpp >>>> ! src/share/vm/interpreter/rewriter.cpp >>>> ! src/share/vm/oops/instanceKlass.cpp >>>> ! src/share/vm/oops/instanceKlass.hpp >>>> ! src/share/vm/oops/instanceKlassKlass.cpp >>>> ! src/share/vm/oops/klassVtable.cpp >>>> ! src/share/vm/oops/klassVtable.hpp >>>> ! src/share/vm/oops/methodOop.hpp >>>> ! src/share/vm/prims/jvm.h >>>> ! src/share/vm/runtime/globals.hpp >>>> ! src/share/vm/utilities/accessFlags.hpp >>>> ! src/share/vm/utilities/growableArray.hpp >>>> ! src/share/vm/utilities/ostream.cpp >>>> ! src/share/vm/utilities/ostream.hpp >>>> + src/share/vm/utilities/resourceHash.hpp >>>> >>>> >>> >>> >> > From james.holmlund at oracle.com Mon Jan 9 08:43:51 2012 From: james.holmlund at oracle.com (Jim Holmlund) Date: Mon, 09 Jan 2012 08:43:51 -0800 Subject: CFV: New Lambda committer: Stuart Marks In-Reply-To: <4F0A32B9.6000404@oracle.com> References: <4F0A32B9.6000404@oracle.com> Message-ID: <4F0B1947.2060303@oracle.com> Vote: yes - jjh On 1/8/2012 4:20 PM, Brian Goetz wrote: > > I hereby nominate Stuart Marks to Lambda Committer. > > Stuart works in the Core Libraries team at Oracle, and has already > contributed several change sets to the Lambda repository. Stuart will > be contributing to the Lambdafication of existing library APIs. Stuart > was previously involved in the API Coinification effort during the > development of Java SE 7. > > Votes are due by January 19, 2012. > > Only current Lambda Committers [1] are eligible to vote on > this nomination. > > For Lazy Consensus voting instructions, see [2]. > > -Brian Goetz > > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > From bitterfoxc at gmail.com Wed Jan 11 09:01:09 2012 From: bitterfoxc at gmail.com (bitter_fox) Date: Thu, 12 Jan 2012 02:01:09 +0900 Subject: Javac throws AssertionError(Unexpected intersection type) for CompoundTypeGenerics In-Reply-To: <4F0C76DA.9080004@oracle.com> References: <4F0C76DA.9080004@oracle.com> Message-ID: Hi, thank you for the fix early. Regards, bitter_fox 2012/1/11 Maurizio Cimadamore > Hi, > this bug has been fixed in the latest push. > > Thanks for the report > Maurizio > From jim.holmlund at sun.com Thu Jan 12 17:37:18 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Fri, 13 Jan 2012 01:37:18 +0000 Subject: hg: lambda/lambda/langtools: AddTypeInferenceComboTest.java. At last. Message-ID: <20120113013722.DEE044794C@hg.openjdk.java.net> Changeset: e758b1cfe881 Author: jjh Date: 2012-01-12 17:36 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e758b1cfe881 AddTypeInferenceComboTest.java. At last. + test/tools/javac/lambda/sqe/typeInference/combo/TypeInferenceComboTest.java From jim.holmlund at sun.com Fri Jan 13 12:44:51 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Fri, 13 Jan 2012 20:44:51 +0000 Subject: hg: lambda/lambda/langtools: Add two new lambdaExpression tests Message-ID: <20120113204459.6491847966@hg.openjdk.java.net> Changeset: d46f8917fab1 Author: jjh Date: 2012-01-13 12:44 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/d46f8917fab1 Add two new lambdaExpression tests Reviewed-by: mcimadamore Contributed-by: sue.wei at oracle.com + test/tools/javac/lambda/sqe/lambdaExpression/SamConversion.java + test/tools/javac/lambda/sqe/lambdaExpression/SamConversionComboTest.java From jim.holmlund at sun.com Wed Jan 25 15:12:34 2012 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Wed, 25 Jan 2012 23:12:34 +0000 Subject: hg: lambda/lambda/langtools: Add SAM conversion tests to the methodReference tests Message-ID: <20120125231239.CB7C2471AC@hg.openjdk.java.net> Changeset: 210edd66b011 Author: jjh Date: 2012-01-25 15:11 -0800 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/210edd66b011 Add SAM conversion tests to the methodReference tests Reviewed-by: mcimadamore Contributed-by: sue.wei at oracle.com ! test/tools/javac/lambda/sqe/methodReference/BridgeMethod.java + test/tools/javac/lambda/sqe/methodReference/SamConversion.java + test/tools/javac/lambda/sqe/methodReference/SamConversionComboTest.java From bitterfoxc at gmail.com Thu Jan 26 05:01:51 2012 From: bitterfoxc at gmail.com (bitter_fox) Date: Thu, 26 Jan 2012 22:01:51 +0900 Subject: "(Lambda Expression)#method" or "(Method or Constructor Reference)#method" causes javac to throw NullPointerException Message-ID: Hi. "(Lambda Expression)#method" or "(Method or Constructor Reference)#method" causes javac to throw NullPointerException.(Revision of langtool is 1246.) For example, public class Main { interface SAM { void invoke(); } public static void main(String[] args) { SAM sam = ((SAM)() -> {})#invoke; } } This is the StackTrace: java.lang.NullPointerException at com.sun.tools.javac.comp.LambdaToInnerClass.visitLambda(LambdaToInnerClass.java:90) at com.sun.tools.javac.tree.JCTree$JCLambda.accept(JCTree.java:1495) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.tree.TreeTranslator.visitTypeCast(TreeTranslator.java:328) at com.sun.tools.javac.tree.JCTree$JCTypeCast.accept(JCTree.java:1690) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.tree.TreeTranslator.visitParens(TreeTranslator.java:299) at com.sun.tools.javac.tree.JCTree$JCParens.accept(JCTree.java:1537) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) at com.sun.tools.javac.tree.TreeTranslator.visitNewClass(TreeTranslator.java:280) at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1399) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaToInnerClass.visitReference(LambdaToInnerClass.java:280) at com.sun.tools.javac.tree.JCTree$JCMemberReference.accept(JCTree.java:1844) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.tree.TreeTranslator.visitVarDef(TreeTranslator.java:151) at com.sun.tools.javac.comp.LambdaTranslator.visitVarDef(LambdaTranslator.java:213) at com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:736) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) at com.sun.tools.javac.tree.TreeTranslator.visitBlock(TreeTranslator.java:160) at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:792) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.tree.TreeTranslator.visitMethodDef(TreeTranslator.java:144) at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:676) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) at com.sun.tools.javac.tree.TreeTranslator.visitClassDef(TreeTranslator.java:134) at com.sun.tools.javac.comp.LambdaTranslator.visitClassDef(LambdaTranslator.java:139) at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:598) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.comp.LambdaTranslator.translateTopLevelClass(LambdaTranslator.java:126) at com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1392) at com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1286) at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:885) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:844) at com.sun.tools.javac.main.Main.compile(Main.java:430) at com.sun.tools.javac.main.Main.compile(Main.java:344) at com.sun.tools.javac.main.Main.compile(Main.java:335) at com.sun.tools.javac.Main.compile(Main.java:76) at com.sun.tools.javac.Main.main(Main.java:61) Method or Constructor Reference has a problem like this. For example, SAM println = ((SAM)System.out#println)#invoke; StackTrace: java.lang.NullPointerException at com.sun.tools.javac.comp.LambdaToInnerClass.visitReference(LambdaToInnerClass.java:180) at com.sun.tools.javac.tree.JCTree$JCMemberReference.accept(JCTree.java:1844) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.tree.TreeTranslator.visitTypeCast(TreeTranslator.java:328) at com.sun.tools.javac.tree.JCTree$JCTypeCast.accept(JCTree.java:1690) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.tree.TreeTranslator.visitParens(TreeTranslator.java:299) at com.sun.tools.javac.tree.JCTree$JCParens.accept(JCTree.java:1537) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) at com.sun.tools.javac.tree.TreeTranslator.visitNewClass(TreeTranslator.java:280) at com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1399) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaToInnerClass.visitReference(LambdaToInnerClass.java:280) at com.sun.tools.javac.tree.JCTree$JCMemberReference.accept(JCTree.java:1844) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.tree.TreeTranslator.visitVarDef(TreeTranslator.java:151) at com.sun.tools.javac.comp.LambdaTranslator.visitVarDef(LambdaTranslator.java:213) at com.sun.tools.javac.tree.JCTree$JCVariableDecl.accept(JCTree.java:736) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) at com.sun.tools.javac.tree.TreeTranslator.visitBlock(TreeTranslator.java:160) at com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:792) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.tree.TreeTranslator.visitMethodDef(TreeTranslator.java:144) at com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:676) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:70) at com.sun.tools.javac.tree.TreeTranslator.visitClassDef(TreeTranslator.java:134) at com.sun.tools.javac.comp.LambdaTranslator.visitClassDef(LambdaTranslator.java:139) at com.sun.tools.javac.tree.JCTree$JCClassDecl.accept(JCTree.java:598) at com.sun.tools.javac.tree.TreeTranslator.translate(TreeTranslator.java:58) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:106) at com.sun.tools.javac.comp.LambdaTranslator.translate(LambdaTranslator.java:99) at com.sun.tools.javac.comp.LambdaTranslator.translateTopLevelClass(LambdaTranslator.java:126) at com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1392) at com.sun.tools.javac.main.JavaCompiler.desugar(JavaCompiler.java:1286) at com.sun.tools.javac.main.JavaCompiler.compile2(JavaCompiler.java:885) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:844) at com.sun.tools.javac.main.Main.compile(Main.java:430) at com.sun.tools.javac.main.Main.compile(Main.java:344) at com.sun.tools.javac.main.Main.compile(Main.java:335) at com.sun.tools.javac.Main.compile(Main.java:76) at com.sun.tools.javac.Main.main(Main.java:61) Regards, bitter_fox From maurizio.cimadamore at oracle.com Thu Jan 26 05:51:32 2012 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 26 Jan 2012 13:51:32 +0000 Subject: "(Lambda Expression)#method" or "(Method or Constructor Reference)#method" causes javac to throw NullPointerException In-Reply-To: References: Message-ID: <4F215A64.6030808@oracle.com> On 26/01/12 13:01, bitter_fox wrote: > public class Main > { > interface SAM > { > void invoke(); > } > > public static void main(String[] args) > { > SAM sam = ((SAM)() -> {})#invoke; > } > } Thanks for the report and the test case, I found a fix - I will test it and push it soon. Maurizio From maurizio.cimadamore at oracle.com Thu Jan 26 07:28:10 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 26 Jan 2012 15:28:10 +0000 Subject: hg: lambda/lambda/langtools: Fix: lambda expression/method reference lead to NPE when part of method reference qualifier expression Message-ID: <20120126152813.66407471CE@hg.openjdk.java.net> Changeset: e4a613c3894f Author: mcimadamore Date: 2012-01-26 15:27 +0000 URL: http://hg.openjdk.java.net/lambda/lambda/langtools/rev/e4a613c3894f Fix: lambda expression/method reference lead to NPE when part of method reference qualifier expression ! src/share/classes/com/sun/tools/javac/comp/LambdaTranslator.java + test/tools/javac/lambda/MethodReference35.java