[
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)
