Bug ID: JDK-8159375 Lambda processing broken in build 122

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 9
9Resolved

weblogic.nodemanager.server.provider.WeblogicCacheServerTest >
testConstructor FAILED
    java.lang.BootstrapMethodError: java.lang.IncompatibleClassChangeError:
Inconsistent constant data for
com/tangosol/net/options/WithConfiguration.lambda$autoDetect$0()Ljava/lang/Str
ing; at index 37
        at
com.tangosol.net.options.WithConfiguration.autoDetect(WithConfiguration.java:4
4)
        at
com.tangosol.net.ScopedCacheFactoryBuilder.<clinit>(ScopedCacheFactoryBuilder.
java:587)
        at java.lang.Class.forName0(java.base@9-ea/Native Method)
        at java.lang.Class.forName(java.base@9-ea/Class.java:294)
        at
com.tangosol.net.CacheFactory.getCacheFactoryBuilderInternal(CacheFactory.java
:87)
        at
com.tangosol.net.CacheFactory.getCacheFactoryBuilder(CacheFactory.java:64)
        at
com.tangosol.net.CacheFactory.getConfigurableCacheFactory(CacheFactory.java:15
4)
        at
com.tangosol.net.CacheFactory.getConfigurableCacheFactory(CacheFactory.java:13
6)
        at
weblogic.nodemanager.server.provider.WeblogicCacheServerTest.testConstructor(W
eblogicCacheServerTest.java:16)
.
        Caused by:
        java.lang.IncompatibleClassChangeError: Inconsistent constant data
for
com/tangosol/net/options/WithConfiguration.lambda$autoDetect$0()Ljava/lang/Str
ing; at index 37
            at
com.tangosol.net.options.WithConfiguration.autoDetect(WithConfiguration.java:4
4)
            ... 8 more
.

Updating to ASM 5.1 resolved this exception.
20-06-2016
I think this can be closed as not an issue (for the JVM at least). I'll file a separate bug to improve the error message so this could have taken a bit less time to track down.
14-06-2016
This looks to fall out from the JDK-8145148. The issue has been tracked down to the Apache Shade plugin and is being tracked here: https://issues.apache.org/jira/browse/MSHADE-228
14-06-2016
We have a class (ScopedCacheFactoryBuilder) that has a static reference: . protected static final String URI_DEFAULT = WithConfiguration.autoDetect().getLocation(); . This calls autoDetect() which is implemented as a lambda: . public interface WithConfiguration extends Session.Option { . String getLocation(); . @Options.Default static WithConfiguration autoDetect() { return () -> "$Default$"; } . static WithConfiguration using(String sUri) throws ConfigurationException { return () -> sUri; } } . That should be sufficient to reproduce the issue, however feel free to ask for more info if needed.
13-06-2016
Here's the change in jdk-9+122 that I assume is tickling this issue: https://bugs.openjdk.java.net/browse/JDK-8145148 . It's possible that CONSTANT_MethodHandle_info is generated with the wrong reference kind and hopefully this is easy to track down. If using ASM then this is specified when constructing a org.objectweb.asm.Handle. . Coleen Phillimore is the engineer in the HotSpot runtime team that implemented this change. She is expecting some fallout from this change and has agreed to out help diagnosing any issues. . Within Oracle, then the latest JDK 9 promoted builds are available here: http://jre.us.oracle.com/java/re/jdk/9/promoted/latest/bundles/
13-06-2016

Relates :	JDK-8159470 - Error message for ICCE for MethodHandle constant pool not helpful
Relates :	JDK-8145148 - InterfaceMethod CP entry pointing to a class should cause ICCE