[jira] [Comment Edited] (GROOVY-10775) VerifyError: Expecting a stackmap

["Darryl L. Miles (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-10775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17614546#comment-17614546 ] 

Darryl L. Miles edited comment on GROOVY-10775 at 10/9/22 12:15 AM:
--------------------------------------------------------------------

Have attached a full project.  Am able to reproduce what I saw with:

 

java -version  ### (reports 1.8)
cd ${project.basedir}
mvn -Dmaven.test.skip=true -Dmaven.compiler.target=1.6 clean verify
docker run --rm -f src/main/docker/Dockerfile.jdk17 .

Inside docker will use JDK17 and run:  mvn -Dmaven.compiler.source=1.7 -Dmaven.compiler.target=1.7 -DtargetBytecode=1.6 test

This uses JDK1.8 to build the project sucessfully (without running tests) targetting 1.6.
Then the docker will rerun the compiled project tests in JDK17.  Without recompiling, as timestamps should be uptodate from the copied into docker targets/**.

Note the JDK17 compiler or JavaC won't let you specify 1.6 it seems, so have to use 1.7 as minimum and ask Groovy to generate for 1.6 (which is compatible with anything later)

 

There is a Dockerfile.jdk11 and Dockerfile.jdk8 to more easiy see the same error under other JDK versions, but they can target=1.6 which causes targetBytecode=1.6 by default.

However maybe you will tell targetting 1.6 support is over now ?
But this explains what I saw and what I am able to reproduce to you.

Please see comments in pom.xml and Dockerfile.jdk* files for more information to assist testing.

 

Maybe the ZIP file project is useful to use as a master template to hand out to people needing to prove their bytecode problems in the same way, so I license under same license as Groovy itself.

 

Thanks for looking at the bug report.


was (Author: dlmiles):
Have attached a full project.  Am able to reproduce what I saw with:

 

java -version  ### (reports 1.8)
cd ${project.basedir}
mvn -Dmaven.test.skip=true -Dmaven.compiler.target=1.6 clean verify
docker run --rm -f src/main/docker/Dockerfile.jdk17 .

### Inside docker will use JDK17 and run:  mvn -Dmaven.compiler.source=1.7 -Dmaven.compiler.target=1.7 -DtargetBytecode=1.6 test

This uses JDK1.8 to build the project sucessfully (without running tests) targetting 1.6.
Then the docker will rerun the compiled project tests in JDK17.  Without recompiling, as timestamps should be uptodate from the copied into docker targets/**.

Note the JDK17 compiler or JavaC won't let you specify 1.6 it seems, so have to use 1.7 as minimum and ask Groovy to generate for 1.6 (which is compatible with anything later)

 

There is a Dockerfile.jdk11 and Dockerfile.jdk8 to more easiy see the same error under other JDK versions, but they can target=1.6 which causes targetBytecode=1.6 by default.

However maybe you will tell targetting 1.6 support is over now ?
But this explains what I saw and what I am able to reproduce to you.

Please see comments in pom.xml and Dockerfile.jdk* files for more information to assist testing.

 

Maybe the ZIP file project is useful to use as a master template to hand out to people needing to prove their bytecode problems in the same way, so I license under same license as Groovy itself.

 

Thanks for looking at the bug report.

> VerifyError: Expecting a stackmap
> ---------------------------------
>
>                 Key: GROOVY-10775
>                 URL: https://issues.apache.org/jira/browse/GROOVY-10775
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 3.0.13
>         Environment: JDK8, JDK11, JDK17, Windows, OpenJDK, Oracle
>            Reporter: Darryl L. Miles
>            Priority: Major
>         Attachments: GROOVY10775.zip, NetworkPortSpec.groovy
>
>
> Don't think this is a dupe of other open bugs.
> This error does not concern invokedynamic or invokespecial like the others.
> Originally the application is targetting 1.6 with JDK8.
> Bug I can not make the problem go away with JDK11, JDK17 and targeting 17, also tried a mix of Oracle and Red Hat JDKs



--
This message was sent by Atlassian Jira
(v8.20.10#820010)