requestfactory-apt fails with records in client code

[dodgex]

I just tried to use a record in my GWT client code but the project wont build anymore, see the error/stactrace below.

I am not yet sure, what exactly the problem is here or why exactly this is a problem. When I somehow find additional information, I will add them to this issue.

Ttested on Temurin 21.0.4+7 as well as 21.0.6+7 JDK.

/src/main/java/gwt_rf_record/MyRecord.java:[3,31] javax.lang.model.element.UnknownElementException: Unknown element: "myField"
        at java.compiler@21.0.6/javax.lang.model.util.AbstractElementVisitor6.visitUnknown(AbstractElementVisitor6.java:125)
        at java.compiler@21.0.6/javax.lang.model.element.ElementVisitor.visitRecordComponent(ElementVisitor.java:223)
        at java.compiler@21.0.6/javax.lang.model.util.AbstractElementVisitor6.visitRecordComponent(AbstractElementVisitor6.java:161)
        at jdk.compiler/com.sun.tools.javac.code.Symbol$RecordComponent.accept(Symbol.java:1897)
        at java.compiler@21.0.6/javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:151)
        at com.google.web.bindery.requestfactory.apt.ScannerBase.scan(ScannerBase.java:76)
        at com.google.web.bindery.requestfactory.apt.ScannerBase.scan(ScannerBase.java:37)
        at java.compiler@21.0.6/javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:138)
        at java.compiler@21.0.6/javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:191)
        at com.google.web.bindery.requestfactory.apt.Finder.visitType(Finder.java:42)
        at com.google.web.bindery.requestfactory.apt.Finder.visitType(Finder.java:26)
        at jdk.compiler/com.sun.tools.javac.code.Symbol$ClassSymbol.accept(Symbol.java:1615)
        at java.compiler@21.0.6/javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:151)
        at com.google.web.bindery.requestfactory.apt.ScannerBase.scan(ScannerBase.java:76)
        at com.google.web.bindery.requestfactory.apt.ScannerBase.scan(ScannerBase.java:37)
        at java.compiler@21.0.6/javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:138)
        at com.google.web.bindery.requestfactory.apt.RfValidator.process(RfValidator.java:84)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:1021)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:937)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1265)
        at jdk.compiler/com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1380)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1272)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:946)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.lambda$doCall$0(JavacTaskImpl.java:104)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.invocationHelper(JavacTaskImpl.java:152)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:100)
        at jdk.compiler/com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:94)
        at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:136)
        at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:183)
        at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:1140)
        at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:193)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:126)
        at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2(MojoExecutor.java:328)
        at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute(MojoExecutor.java:316)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:174)
        at org.apache.maven.lifecycle.internal.MojoExecutor.access$000(MojoExecutor.java:75)
        at org.apache.maven.lifecycle.internal.MojoExecutor$1.run(MojoExecutor.java:162)
        at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute(DefaultMojosExecutionStrategy.java:39)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:159)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:105)
        at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:73)
        at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:53)
        at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:118)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:261)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:173)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:101)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:906)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:283)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:206)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:283)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:226)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:407)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:348)

Setup to repo. mvn compile triggers the issue.

src/main/java/gwt_rf_record/MyRecord.java

package gwt_rf_record;

public record MyRecord(String myField) {}

pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>not.a.group</groupId>
    <artifactId>gwt-rf-record</artifactId>
    <version>0.0.0</version>
    <packaging>jar</packaging>

    <properties>
        <java.version>17</java.version>
        <gwt.version>2.12.2</gwt.version>

        <maven.compiler.source>${java.version}</maven.compiler.source>
        <maven.compiler.target>${java.version}</maven.compiler.target>
        <maven.compiler.release>${java.version}</maven.compiler.release>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.gwtproject.web.bindery</groupId>
            <artifactId>requestfactory-client</artifactId>
            <version>${gwt.version}</version>
        </dependency>
        <dependency>
            <groupId>org.gwtproject.web.bindery</groupId>
            <artifactId>requestfactory-apt</artifactId>
            <version>${gwt.version}</version>
            <scope>provided</scope>
        </dependency>
    </dependencies>
</project>

[niloc132]

Thanks for this, should be straightforward to resolve - while we can't directly handle records here (that would raise the minimum java version above 11 just for this one change), we should be able to override the visitUnknown() to log/warn instead of throw.

Outside of small sample projects, we continue to advise that classpaths be isolated even when sharing code. As a workaround, consider moving your RF contexts/proxies and factory into its own project so that the processor only consumes its sources rather than also seeing all other client code.

RequestFactory has its own unique constraints in this area (as the client must depend on proxies, and proxies may depend on jvm-only types), but the graph can look like this:

graph TD;
    client(GWT client code);
    rf(RequestFactory proxies);
    service(JVM-only service layer code, with DAOs and entities);
    webapp(war project deployed to your server);
    client --> rf;
    rf --> service;
    webapp --> service;
    webapp --> client;

Loading

Using @ProxyFor and friends can let you use string literals instead of class literals, but you'll still need the service layer bytecode on the classpath when running the processor.

[dodgex]

Thanks for the fast response.

Outside of small sample projects, we continue to advise that classpaths be isolated even when sharing code. As a workaround, consider moving your RF contexts/proxies and factory into its own project so that the processor only consumes its sources rather than also seeing all other client code.

I considered doing that, extracting proxies and contexts into thier own module, but thats not a job for a friday afternoon. :D