This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I have the following code that show as an error but it compiles without problems in jdk lambda b97: public enum Brand { BRAND1, BRAND2; public static Collection<String> toName(Collection<? extends Brand> brands) { //no suitable method found for collect(Collector<Object,CAP#1,List<Object>>) // method Stream.<R#1>collect(Supplier<R#1>,BiConsumer<R#1,? super String>,BiConsumer<R#1,R#1>) is not applicable // (cannot infer type-variable(s) R#1 // (actual and formal argument lists differ in length)) // method Stream.<R#2,A>collect(Collector<? super String,A,R#2>) is not applicable // (cannot infer type-variable(s) R#2,A,T#2 // (argument mismatch; Collector<String,CAP#2,List<String>> cannot be converted to Collector<? super String,CAP#3,List<String>>)) // where R#1,T#1,R#2,A,T#2 are type-variables: // R#1 extends Object declared in method <R#1>collect(Supplier<R#1>,BiConsumer<R#1,? super T#1>,BiConsumer<R#1,R#1>) // T#1 extends Object declared in interface Stream // R#2 extends Object declared in method <R#2,A>collect(Collector<? super T#1,A,R#2>) // A extends Object declared in method <R#2,A>collect(Collector<? super T#1,A,R#2>) // T#2 extends Object declared in method <T#2>toList() // where CAP#1,CAP#2,CAP#3 are fresh type-variables: // CAP#1 extends Object from capture of ? // CAP#2 extends Object from capture of ? // CAP#3 extends Object from capture of ? //---- return brands.parallelStream() .map(Brand::name) .collect(toList()); } }
Unfortunately, I cannot reproduce the problem in the current dev build. What is the build number of your NB IDE? Thanks.
Sorry. Here are the versions it is the latest nightly build of jdk8: Product Version = NetBeans IDE Dev (Build jdk8lambda-1773-on-20130710) Operating System = Linux version 3.8.0-26-generic running on amd64 Java; VM; Vendor = 1.7.0_25 Runtime = Java HotSpot(TM) 64-Bit Server VM 23.25-b01
Is there any particular reason to use nightly jdk8lambda builds instead of regular NB 7.4 daily builds?
Yes, I am trying with the lambda jdk. Is it already integrated with the regular branch of NetBeans? (In reply to comment #3) > Is there any particular reason to use nightly jdk8lambda builds instead of > regular NB 7.4 daily builds?
Yes. Preview of the JDK 8 support (including lambdas) is already part of the regular NB 7.4 daily builds. The problem is that jdk8lambda builds are based on slightly older javac version than regular trunk builds. However, the level of the JDK 8 support should be similar. Could you please try to use the current trunk daily build and tell us whether it works for you or not? Thanks.
(In reply to comment #5) > Yes. Preview of the JDK 8 support (including lambdas) is already part of the > regular NB 7.4 daily builds. The problem is that jdk8lambda builds are based on > slightly older javac version than regular trunk builds. However, the level of That's actually not completely correct: the jdk8lambda builds are daily builds (from the jet-main repository)+one patch: java freeforms accept source level 1.8 for schema version /3, and all java freeforms have forced source level 1.8. This build exists exclusively to support JDK8 development, and once JDK8 switches to java freeform version /4 (which allows source level 1.8), it will be discontinued. > the JDK 8 support should be similar. > > Could you please try to use the current trunk daily build and tell us whether > it works for you or not? Thanks. Lambda JDK may contain some library changes compared to non-lambda JDKs that are causing the compile-time errors, and our slightly older javac may not be able to accept that - I'll try.
As I've seen the same happen in daily build Product Version = NetBeans IDE Dev (Build 20130710-224f97ca63ba)
I tried to reproduce using the lambda JDK, and it is reproducible. Not reproducible using my (relatively) recent jdk8/tl JDK build. Collector takes three type parameters in lambda JDK, while it takes only two in jdk8/tl, and it seems that added type parameter may be the place where the inference fails. Unfortunately, my custom recent jdk8/tl/langtools javac build fails in the same way when using lambda JDK as bootclasspath, so the changes that allow this code to compile were not yet propagated from lambda into jdk8/tl, and much less into jdk8/jdk8 from where we currently synchronize the javac.
Fixed in jet-main. http://hg.netbeans.org/jet-main/rev/8ed641e20fa2