No easy way to load stubs as Maven dependencies

[obfischer]

I am using the Checkerframework in a Maven multi-modules project. For an external dependency I had to create a stubs file. The stubs file is part of a jar, which I create in a dedicated Maven module, so that I can reuse it.

According to the documentation and my searches on the Internet, the only way to use it is via -Astubs=....

All examples I have seen use a full qualified path (-Astubs=/some/dir/my.jar). For a Maven project, serveral persons contribute too, each one using his own directory structure, it is impossible to rely on a hard coded path.

So, it would be very helpful and would make it much easier use custom, project specific stub files, it it would be possible to put them simply in a jar and add it to the classpath, so that it is available during compilation.

Currently I use the following workaround currently to my jar as Maven artifact:

<compilerArgs combine.children="append">
    <arg>-Aproject=${project.groupId}/${project.artifactId}</arg>
    <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED</arg>
    <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.code=ALL-UNNAMED</arg>
    <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED</arg>
    <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.file=ALL-UNNAMED</arg>
    <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED</arg>
    <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.model=ALL-UNNAMED</arg>
    <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED</arg>
    <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.tree=ALL-UNNAMED</arg>
    <arg>-J--add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED</arg>
    <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.comp=ALL-UNNAMED</arg>
    <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.main=ALL-UNNAMED</arg>
    <arg>-J--add-opens=jdk.compiler/com.sun.tools.javac.processing=ALL-UNNAMED</arg>

    <!-- Workaround to use the jar with stubs -->
    <arg>-Astubs=${settings.localRepository}/com/example/checker-stubs/${project.version}/checker-stubs-${project.version}.jar</arg>

    <arg>-AstubWarnIfNotFound</arg>
    <arg>-AstubDebug</arg>
</compilerArgs>

Or is there a better way to achive my goal?

[msridhar]

@obfischer I don't know of a better way to achieve your goal. I agree this is an annoyance. A feature we could add would be to parse additional stub files from jars in the processor path, loading them via a service loader. See, e.g., how NullAway loads stubx files:

https://github.com/uber/NullAway/blob/ccc7f82e09f2a0f6e6149d97aa6a1ab824608030/nullaway/src/main/java/com/uber/nullaway/handlers/StubxCacheUtil.java#L90-L93
https://github.com/uber/NullAway/blob/ccc7f82e09f2a0f6e6149d97aa6a1ab824608030/nullaway/src/main/java/com/uber/nullaway/jarinfer/JarInferStubxProvider.java#L6
Example provider: https://github.com/uber/NullAway/blob/ccc7f82e09f2a0f6e6149d97aa6a1ab824608030/jar-infer/test-java-lib-jarinfer/src/main/java/com/uber/nullaway/jarinfer/provider/TestProvider.java

The Checker Framework code for parsing stub files is here. I don't think it would be too hard to enhance it with this functionality, if someone wants to put up a PR.

[Calvin-L]

Possible dup: #4058

[Calvin-L]

I was also thinking of implementing this feature at some point, since this would be a big help to me.

@obfischer FWIW, I've been using dependency:properties as a workaround. The setup is roughly

1. Create a stubs module
2. Add the stubs module to every other module's <dependencies> with <scope>provided</scope>
3. Add a dependency:properties execution to every other module's <build>
4. In <compilerArgs> use <arg>-Astubs=${stubs-group:stubs-artifactId:jar}</arg>

That setup is better than using hardcoded paths, but it also feels extremely clunky and has some sharp edges. It would be much cleaner to just add the stubs module to the <annotationProcessorPaths> section.

[obfischer]

Hi @Calvin-L, I have this feature still in mind, but have to finish some other topics like a small lib for semantic versions, running my company and client project. I will put this feature at position #2 in my bucket list of OSS work.