PL/Java is a free add-on module that brings Java™ Stored Procedures, Triggers, Functions, Aggregates, Operators, Types, etc., to the PostgreSQL™ backend.
Recent versions of javac warn that annotation processing might not happen in the future unless --processor, --processor-path, --processor-module-path, or some -proc option is explicitly given. Nothing was going to break, because the POMs where annotation processing needs to happen already set --processor-module-path. But that doesn't silence the warning. Only an explicit -proc:full or -processor org.postgresql.pljava.annotation.processing.DDRProcessor accomplishes that. Because -proc:full is unrecognized before Java 21, but the longwinded -processor spec works in all supported versions, the longwinded form is used here (even though it seems a complete waste of the elegance of the original processor discovery scheme).
Warnings were also appearing in a couple of compilations where no annotation processing was needed or expected. When compiling the PGXS plugin, the warning appeared because an unexpected and unneeded processor org.eclipse.sisu.space.SisuIndexAPT6 was being found in one of the 70 classpath elements glommed together to build a Maven plugin. When building the pljava-packaging classes, the POM names the other PL/Java modules as dependencies (because they must exist before they can be packaged), with the side effect of adding them to the classpath, so PL/Java's processor is found, though not needed for the packaging code. In both of those modules, add -proc:none (which is recognized in all supported versions; only -proc:full was newer).
The longwinded approach of naming an exact processor class might be hygienically preferable to the broad -proc:full, as less prone to surprises when another processor like SisuIndexAPT6 happens to exist on the classpath. (Assuming the other processor is nonmalicious, and is looking for annotations the code being compiled doesn't use, the processor wouldn't be expected to do anything, yielding surprise of the mildest possible kind. Still, anyone very averse to surprise might prefer to name the expected processor explicitly.)
Recent versions of
javacwarn that annotation processing might not happen in the future unless--processor,--processor-path,--processor-module-path, or some-procoption is explicitly given. Nothing was going to break, because the POMs where annotation processing needs to happen already set--processor-module-path. But that doesn't silence the warning. Only an explicit-proc:fullor-processor org.postgresql.pljava.annotation.processing.DDRProcessoraccomplishes that. Because-proc:fullis unrecognized before Java 21, but the longwinded-processorspec works in all supported versions, the longwinded form is used here (even though it seems a complete waste of the elegance of the original processor discovery scheme).Warnings were also appearing in a couple of compilations where no annotation processing was needed or expected. When compiling the PGXS plugin, the warning appeared because an unexpected and unneeded processor
org.eclipse.sisu.space.SisuIndexAPT6was being found in one of the 70 classpath elements glommed together to build a Maven plugin. When building thepljava-packagingclasses, the POM names the other PL/Java modules as dependencies (because they must exist before they can be packaged), with the side effect of adding them to the classpath, so PL/Java's processor is found, though not needed for the packaging code. In both of those modules, add-proc:none(which is recognized in all supported versions; only-proc:fullwas newer).The longwinded approach of naming an exact processor class might be hygienically preferable to the broad
-proc:full, as less prone to surprises when another processor likeSisuIndexAPT6happens to exist on the classpath. (Assuming the other processor is nonmalicious, and is looking for annotations the code being compiled doesn't use, the processor wouldn't be expected to do anything, yielding surprise of the mildest possible kind. Still, anyone very averse to surprise might prefer to name the expected processor explicitly.)