Created attachment 154700 [details]
IDE log

Unfortunately, I cannot reproduce the problem. Could you please create a simple test case and attach it to the issue? Thanks.

Created attachment 154772 [details]
Processor

Simply add this processor to its own project. You will need to expand the imported static constants to "javax.ejb.Stateless" and "javax.inject.Inject".
Include the processor FQN in META-INF/services/javax.annotation.processing.Processor . 

Then create a new Java project with any Java files annotated with @Stateless and the processor jar in its classpath.

Created attachment 154794 [details]
Test Case

Test Netbeans Project demonstrating bug in SystemDictionary::find_method_handle_type(Symbol*,KlassHandle,Thread*) which does not use the caller class loader when the signature is materialized on boot class path. Such a resolution does not work with inverse class loader.

The SystemDictionary::find_method_handle_type(Symbol*,KlassHandle,Thread*) does not use the caller class loader when the signature is materialized on boot class path. Such a resolution does not work with inverse class loader. See: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/share/vm/classfile/systemDictionary.cpp#l2412

The test can be executed by:

export JAVA_HOME=<path_to_jdk8>; ant run

The test failure:
Exception in thread "main" java.lang.BootstrapMethodError: call site initialization exception
at java.lang.invoke.CallSite.makeSite(CallSite.java:341)
at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:307)
at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:297)
at indyclzlkp.Action.run(Action.java:15)
at indyclzlkp.Main.main(Main.java:22)
Caused by: java.lang.invoke.LambdaConversionException: Invalid receiver type class javax.lang.model.element.ElementKind; not a subtype of implementation type class javax.lang.model.element.ElementKind
at java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:233)
at java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java:303)
at java.lang.invoke.CallSite.makeSite(CallSite.java:302)

Created attachment 154834 [details]
nb-javac diff file

Created attachment 154835 [details]
nb patch file

Added a patch for javac and nb which tries to replace using byte code patching calls to java.lang.invoke.LambdaMetafactory to custom one which corrects wrong MethodTypes creed by the SystemDictionary::find_method_handle_type(Symbol*,KlassHandle,Thread*).
Unfortunately the wrong klassOop referencing class on BCP is taken from "somewhere".

As seen from:
java.lang.invoke.WrongMethodTypeException: MethodHandle(RoundEnvironment)Supplier should be of type (RoundEnvironment)Supplier
	at java.lang.invoke.CallSite.wrongTargetType(CallSite.java:194)
	at java.lang.invoke.CallSite.makeSite(CallSite.java:335)
Caused: java.lang.BootstrapMethodError: call site initialization exception
	at java.lang.invoke.CallSite.makeSite(CallSite.java:341)
	at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:307)
	at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:297)
	at ap.Ap.process(Ap.java:24)

The patch problem is that CallSite.makeSite verifies compatibility of the MethodType type and created CallSite. The CallSite created by the patched LambdaMetaFactory has correct type but the expected type is wrong.
Possible solution may be not to create a new MethodType but to rewrite the sysDict created one by reflection. I will try.

Created attachment 154854 [details]
nb-javac diff file

Created attachment 154940 [details]
nb-javac diff file

Doing the byte code patching only on affected JDKs.

Created attachment 154944 [details]
nb-javac diff file

Sure it cannot work without sneaky throw.

Seems reasonable to me.

Fixed: nb-javac fcc3354424b2

Fixed jet-main db96a3afb14a.
JDK 8 < u51 are workarounding the hotspot problem by byte code patching.
JDK 8 >= u51 - the problem is already fixed in hotspot.

Integrated into 'main-silver', will be available in build *201507280002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/db96a3afb14a
User: Tomas Zezula <tzezula@netbeans.org>
Log: #253549:Processors that use lambdas are completely broken in the IDE

I've fixed the problem but the test annotation processor was very simple.
Please, can someone verify the fix? If the verification comes today I will be able to integrate the fix to beta.
Thanks

I can only verify this problem is no longer reproducible, but I cannot say if it could broke something or not. This is not my area, I don't know much about it.


Product Version: NetBeans IDE Dev (Build Trunk-Build-1303-on-20150728)
Java: 1.8.0_45; Java HotSpot(TM) 64-Bit Server VM 25.45-b02
Runtime: Java(TM) SE Runtime Environment 1.8.0_45-b14
System: Linux version 3.16.0-30-generic running on amd64; UTF-8; en_US (nb)

Integrated into release81_beta d6594b2a7e68

Still reproducible:

INFO [com.sun.tools.javac.processing.JavacProcessingEnvironment]: Annotation pro
cessing error:
java.lang.invoke.LambdaConversionException: Type mismatch in captured lambda par
ameter 0: expecting interface javax.annotation.processing.RoundEnvironment, foun
d interface javax.annotation.processing.RoundEnvironment
        at java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafact
oryArgs(AbstractValidatingLambdaMetafactory.java:256)
        at java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java
:303)
        at sun.reflect.GeneratedMethodAccessor112.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at com.sun.tools.hc.LambdaMetafactory.metafactory(LambdaMetafactory.java
:81)
        at java.lang.invoke.CallSite.makeSite(CallSite.java:302)
Caused: java.lang.BootstrapMethodError: call site initialization exception
        at java.lang.invoke.CallSite.makeSite(CallSite.java:341)
        at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNat
ives.java:307)
        at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives
.java:297)
        at br.com.tecsinapse.processors.PossiblyBrokenStatelessProcessor.doProce
ss(PossiblyBrokenStatelessProcessor.java:38)
        at br.com.tecsinapse.processors.BaseProcessor.process(BaseProcessor.java
:19)
[catch] at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcess
or(JavacProcessingEnvironment.java:823)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment.access$400(
JavacProcessingEnvironment.java:91)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment$DiscoveredP
rocessors$ProcessorStateIterator.runContributingProcs(JavacProcessingEnvironment
.java:640)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(J
avacProcessingEnvironment.java:1047)
        at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessin
g(JavacProcessingEnvironment.java:1145)
        at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler
.java:1236)
        at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler
.java:1123)
        at com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:375)
        at com.sun.tools.javac.api.JavacTaskImpl.enter(JavacTaskImpl.java:310)
        at org.netbeans.modules.java.source.parsing.JavacParser.moveToPhase(Java
cParser.java:630)
        at org.netbeans.modules.java.source.parsing.JavacParser.getResult(JavacP
arser.java:496)
        at org.netbeans.modules.java.source.parsing.JavacParser.getResult(JavacP
arser.java:162)
        at org.netbeans.modules.parsing.impl.TaskProcessor.callGetResult(TaskPro
cessor.java:631)
        at org.netbeans.modules.parsing.impl.SourceCache.getResult(SourceCache.j
ava:262)
        at org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.run(
TaskProcessor.java:798)
        at org.openide.util.lookup.Lookups.executeWith(Lookups.java:304)
        at org.netbeans.modules.parsing.impl.TaskProcessor$RequestPerformer.exec
ute(TaskProcessor.java:725)
        at org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(Ta
skProcessor.java:686)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:51
1)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1443
)
        at org.netbeans.modules.openide.util.GlobalLookup.execute(GlobalLookup.j
ava:68)
        at org.openide.util.lookup.Lookups.executeWith(Lookups.java:303)
        at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java
:2058)

I use main-silver, but:

C:\projetos\main-silver>hg log --rev "ancestors(.) and db96a3afb14a"
revisÒo:      289616:db96a3afb14a
pai:          289477:0ca817cb6fe1
usußrio:      Tomas Zezula <tzezula@netbeans.org>
data:         Mon Jul 27 14:46:26 2015 +0200
sumßrio:      #253549:Processors that use lambdas are completely broken in the IDE

My checkout contains your change :-S

The processor is the one from the attachement (https://netbeans.org/bugzilla/attachment.cgi?id=154772)?
If so I will add the logging options.
Also can you try JDK 1.8.0 u51?
Thanks

Yes, it is that processor.

About trying JDK 8u51, I'm not so sure. I'm about to go on vacations and I need to get my work finished before and installing a new JDK might mess up something... I'll try, but can't promise though, unfortunately.

OK, no problem I will add logging and let you know.

It's not enough to patch invokedType but the implMethod MethodHandle needs to be patched as well. The funny past is that when the implMethod is broken the invokeType is fine. So anything can be broken in invokedynamic + lambda on JDK 8 < u51 with inversed CL, the only certain thing is that never all params are valid. :-)

http://hg.netbeans.org/main/nb-javac/rev/15bf7cdb3577

Fixed jet-main: http://hg.netbeans.org/jet-main/rev/46de5752faae

Integrated into 'main-silver', will be available in build *201507310002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/46de5752faae
User: Tomas Zezula <tzezula@netbeans.org>
Log: #253549:Processors that use lambdas are completely broken in the IDE

Integrated into 'main-silver', will be available in build *201508010002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/78ac0e59785a
User: Tomas Zezula <tzezula@netbeans.org>
Log: #253549:Processors that use lambdas are completely broken in the IDE