[
https://issues.apache.org/jira/browse/GROOVY-11806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-11806:
---------------------------------
Component/s: Stub generator / Joint compiler
> Groovy 5: joint compilation generates stubs without imports for implemented
> interfaces in other packages (works in 4.x)
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-11806
> URL: https://issues.apache.org/jira/browse/GROOVY-11806
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Stub generator / Joint compiler
> Affects Versions: 5.0.2
> Reporter: Johan Haleby
> Priority: Major
>
> Joint compilation with Groovy 5.x generates invalid Java stubs for Groovy
> classes that implement interfaces located in a different package. The
> generated stubs are missing imports for those interfaces and other referenced
> types, which causes javac to fail with cannot find symbol errors.
> The same project works correctly with Groovy 4.0.x. You can try it out
> yourselves by doing this:
> {code:java}
> $ git clone [email protected]:rest-assured/rest-assured.git
> $ cd rest-assured
> $ git checkout java17-groovy5
> $ mvn clean install{code}
> h5.
> h5.
> Environment
> * Groovy: 5.0.2
> * Previously worked with 4.0.x
> * JDK: 17
> * Build tool: Maven
> * Groovy integration: org.codehaus.gmavenplus:gmavenplus-plugin
> Maven gmavenplus configuration:
>
> {code:java}
> <plugin>
> <groupId>org.codehaus.gmavenplus</groupId>
> <artifactId>gmavenplus-plugin</artifactId>
> <version>4.2.1</version>
> <dependencies>
> <dependency>
> <groupId>org.apache.groovy</groupId>
> <artifactId>groovy</artifactId>
> <version>5.0.2</version>
> </dependency>
> </dependencies>
> <executions>
> <execution>
> <goals>
> <goal>addSources</goal>
> <goal>addTestSources</goal>
> <goal>generateStubs</goal>
> <goal>compile</goal>
> <goal>generateTestStubs</goal>
> <goal>compileTests</goal>
> <goal>removeStubs</goal>
> <goal>removeTestStubs</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
>
> {code}
>
> h5. Simplified problem description
> * There is a Java interface ResponseSpecification in package
> io.restassured.specification.
> * There is a Groovy class ResponseSpecificationImpl in package
> io.restassured.internal that implements FilterableResponseSpecification and
> ResponseSpecification, and uses other types from different packages
> (Argument, ResponseLogSpecification, etc.).
> * With Groovy 4.0.x, gmavenplus’ generateStubs goal creates valid Java stubs
> for ResponseSpecificationImpl, including correct import statements for all
> referenced types.
> * With Groovy 5.x, the generated stub no longer contains those imports,
> leaving only the simple names. As a result, javac cannot resolve them in the
> io.restassured.internal package and compilation fails.
>
> h5. Example of broken stub (Groovy 5.x)
>
> The generated stub for io.restassured.internal.ResponseSpecificationImpl
> looks like this (excerpt):
>
> {code:java}
> package io.restassured.internal;
> import static io.restassured.http.ContentType.ANY;
> public class ResponseSpecificationImpl
> extends java.lang.Object implements
> FilterableResponseSpecification, groovy.lang.GroovyObject {
> public ResponseSpecificationImpl(String bodyRootPath,
> ResponseSpecification defaultSpec,
> ResponseParserRegistrar rpr,
> io.restassured.config.RestAssuredConfig
> config,
> io.restassured.internal.log.LogRepository
> logRepository) {
> super();
> }
> public ResponseSpecification body(java.util.List<Argument> arguments,
> org.hamcrest.Matcher matcher,
> Object... additionalKeyMatcherPairs) {
> return null; }
> public ResponseSpecification body(String key,
> org.hamcrest.Matcher matcher,
> Object... additionalKeyMatcherPairs) {
> return null; }
> public ResponseLogSpecification log() { return null; }
> public RequestSpecification given() { return null; }
> public ResponseSpecification response() { return null; }
> // ... many other methods referencing ResponseSpecification, Argument,
> // ResponseLogSpecification, RequestSpecification, etc.
> }
> {code}
>
> * FilterableResponseSpecification and ResponseSpecification are simple names
> with no import.
> * Argument, ResponseLogSpecification, RequestSpecification, etc. also appear
> as simple names with no imports.
> * These types actually live in other packages (io.restassured.specification,
> io.restassured.internal.path, …), so from javac’s perspective in package
> io.restassured.internal; they cannot be resolved.
> This leads to errors such as:
>
> {code:java}
> target/generated-sources/groovy-stubs/main/io/restassured/internal/ResponseSpecificationImpl.java:[6,5]
> cannot find symbol
> symbol: class FilterableResponseSpecification
> ...
> target/generated-sources/groovy-stubs/main/io/restassured/internal/ResponseSpecificationImpl.java:[20,51]
> cannot find symbol
> symbol: class Argument{code}
>
>
> h5. Expected behavior
> * Groovy 5.x should generate Java stubs equivalent to Groovy 4.x for joint
> compilation:
> ** All referenced types from other packages should be fully resolvable by
> javac, typically via generated import statements or fully qualified names.
>
> * The Maven build using gmavenplus + maven-compiler-plugin should succeed
> with Groovy 5.x just as it does with Groovy 4.x.
> h5. *Actual behavior*
> * With Groovy 5.x, the stub for a Groovy class implementing interfaces in
> another package is missing necessary imports.
> * maven-compiler-plugin (javac) fails on the generated stub with cannot find
> symbol errors for those interfaces and other referenced types.
> * Downgrading only the Groovy version back to 4.0.x (keeping the rest of the
> Maven configuration identical) makes the problem disappear.
> h3. Notes
> * This looks like a regression in Groovy 5’s stub generation / joint
> compilation compared to Groovy 4.
> * The plugin (gmavenplus) is just invoking Groovy’s stub generator; it does
> not manipulate the contents of the stubs.
> * I can provide a minimal reproducer Maven project (one Java interface in
> package A, one Groovy implementation in package B, joint compilation via
> gmavenplus) if needed.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
