JPMS module

ProxyBuilder ships a module-info.java. The module name is com.svenruppert.proxybuilder. Consumer modules require it the usual way:

module com.example.app {
  requires com.svenruppert.proxybuilder;
}

Transitive dependencies

API-visible types from JavaPoet, java.compiler, the RapidPM core and Dropwizard Metrics are marked transitive in the module descriptor. That means a consumer that requires com.svenruppert.proxybuilder automatically sees those types without an additional requires clause.

If you do not want this and prefer explicit requires for everything, narrow your usage to types that are not on the API surface of ProxyBuilder.

Validating the descriptor

After a build, you can validate that the descriptor matches the actual classes with jdeps:

./mvnw -pl impl dependency:build-classpath -Dmdep.outputFile=target/classpath.txt
jdeps --multi-release 26 \
  --module-path "impl/target/proxybuilder-00.10.00.jar:$(cat impl/target/classpath.txt)" \
  --check com.svenruppert.proxybuilder

The project itself runs this check during release verification.

Opens and exports

ProxyBuilder does not need opens for normal use. The runtime side uses JDK dynamic proxies, which need access to the interface type — the consumer of ProxyBuilder is the one whose interface gets proxied, so the opens (if any) live in the consumer module.

The annotation processor side does not need opens either: the generated sources are compiled into the consumer’s own module and do not cross module boundaries reflectively.

Notes on Gradle

Gradle incremental-annotation-processing metadata is not published yet. The processor works with Gradle, but the build will run the processor on more sources per round than strictly necessary. Maven incremental compile through ./mvnw clean install is the supported path.