I used 1.8.0_161 but so far have only pasted the problematic line into Groovy Console and run it.
Jochen, your change did seem to be missing on 2_5_X but was on the other branches. I just cherry picked it onto 2_5_X. I think we need to close off GROOVY-8338 and clone a new issue with a new reproducer. Cheers, Paul. On Wed, Mar 7, 2018 at 9:37 AM, Jochen Theodorou <blackd...@gmx.org> wrote: > On 06.03.2018 13:23, Andres Almiray wrote: > >> Hello everyone, >> >> I'm in the process of updating the Griffon build to use Groovy 2.4.14 and >> encountered a weird problem in one of the tests >> https://github.com/griffon/griffon/blob/development/subproje >> cts/griffon-javafx-groovy/src/test/groovy/griffon/javafx/Gri >> ffonFXCollectionsExtensionTest.groovy#L78 >> >> The test runs fine with 2.413 but generates the following stacktrace with >> 2.4.14 >> >> java.lang.VerifyError: (class: java_util_function_Function$identity, >> method: callStatic signature: >> (Ljava/lang/Class;[Ljava/lang/Object;)Ljava/lang/Object;) >> Illegal type in constant pool >> > [...] > >> at org.codehaus.groovy.reflection.ClassLoaderForClassArtifacts. >> defineClassAndGetConstructor(ClassLoaderForClassArtifacts.java:82) >> at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.compi >> leStaticMethod(CallSiteGenerator.java:262) >> at org.codehaus.groovy.reflection.CachedMethod.createStaticMeta >> MethodSite(CachedMethod.java:295) >> at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.cr >> eateStaticMetaMethodSite(StaticMetaMethodSite.java:114) >> > [...] > > this is clearly during callsite generation. The generated helper class to > realize the static method call is invalid. I would now go and change the > code to write those classes to disc and then I can look with a "proper" > tool at it. Or I would at least put the ASM verify into the queue > > The "faulty" line is >> >> Function<Integer, Integer> function = Function.identity() >> >> I'm baffled by this error as java.util.function.Function is a core JDK >> type. >> >> Environment >> >> ------------------------------------------------------------ >> Gradle 4.6 >> ------------------------------------------------------------ >> >> Build time: 2018-02-28 13:36:36 UTC >> Revision: 8fa6ce7945b640e6168488e4417f9bb96e4ab46c >> >> Groovy: 2.4.12 >> Ant: Apache Ant(TM) version 1.9.9 compiled on February 2 2017 >> JVM: 1.8.0_162 (Oracle Corporation 25.162-b12) >> OS: Mac OS X 10.12.5 x86_64 >> > > It is also possible that the code is valid on one JVM and not on another. > 1.8.0_162 seems to be the newest JDK 1.8. Did you try that exact java > version as well Paul? > > Steps to reproduce: >> >> $ git clone https://github.com/griffon/griffon.git >> $ cd griffon >> // update gradle.properties with groovyVersion = 2.4.14 >> $ ./gradlew :griffon-javafx-groovy:test >> > > updating gradle.properties is not required, that is set to 2.4.14 already. > Instead you should remove the @Ignore in https://github.com/griffon/gri > ffon/blob/development/subprojects/griffon-javafx-groovy/src/ > test/groovy/griffon/javafx/GriffonFXCollectionsExtensionTest.groovy#L78 > > and this also fails with update 152, which reduces my theory, that is > depending on the JVM version > > Using 2.5.0-beta-3: 712 tests completed, 208 failed. > Using 2.6.0-alpha-2: 712 tests completed, 52 failed > Using 2.6.0-alpha-3: fails with > >> Could not find groovy-all.jar (org.codehaus.groovy:groovy-al >> l:2.6.0-alpha-3). >> Searched in the following locations: >> https://jcenter.bintray.com/org/codehaus/groovy/groovy-all/ >> 2.6.0-alpha-3/groovy-all-2.6.0-alpha-3.jar >> > > did not try 3.0.0-alpha-1, because it is from Nov. last year and did not > have a change I suspect > > GriffonFXCollectionsExtensionTest seems to have worked for 2.5 and 2.6 > though > > Has anyone experimented a similar error? Any hints would be greatly >> appreciated :-) >> > > I think when I tried fixing Stream.of... which is a very similar case, > since this is a static method on an interface as well. So I know that > e34823cbabbce2a90829ead5d83c72806326946d and similar did cause some > trouble and I do know there have been fixes. But I think they got applied > to all branches. Can it be we forgot to backport something that got applied > to 2.5 and 2.6 (and most likely master), but not 2.4? the class itself is > the same in master and in 2.4.14 and on GROOVY_2_6_X... GROOVY_2_5_X seems > to be missing the change?! > > For me this sounds like a "too many branches exception" > > bye Jochen > >
