PL/Java is a free add-on module that brings Java™ Stored Procedures, Triggers, Functions, Aggregates, Operators, Types, etc., to the PostgreSQL™ backend.
Because PL/Java must be compilable on any Java back to release 9, the DDRProcessor cannot refer by name to any SourceVersion enum constant later than RELEASE_9. It also, arguably, should not, because its development and testing rely on the javax.lang.model API as of release 9.
Happily, in practice, later Java releases do not often break the DDRProcessor code, so user Java code for releases later than 9 can be compiled with no difficulty, other than a compiler warning about the processor's source version being pegged at 9. But the warning is an obstacle if the user code is being compiled with a fail-on-warning policy, as in issue #403.
This patch adopts a compromise position, and keeps track of the latest source version for which the annotation processor at least has been seen to pass the CI tests (fully understanding that such testing is no substitute for thoroughly auditing any release-to-release changes in the javax.lang.model APIs and what impact they could have on the processor!). It will compute its "declared" supported source version to be the earlier of SourceVersion.latestSupported() and that latest tested version.
As a result, it should eliminate the compiler warning when running on any Java version in that range. The warning will reappear when running a compile on a later Java version, and it should be easy to alleviate that with a PL/Java release that bumps the latest_tested version.
Merely passing the CI tests as normally run isn't enough, because the project is built with a --release 9 option. Before actually bumping latest_tested, a test build (at least of the pljava-examples project) should be done on the Java release in question and without the limiting --release option.
Because PL/Java must be compilable on any Java back to release 9, the
DDRProcessorcannot refer by name to anySourceVersionenum constant later thanRELEASE_9. It also, arguably, should not, because its development and testing rely on thejavax.lang.modelAPI as of release 9.Happily, in practice, later Java releases do not often break the
DDRProcessorcode, so user Java code for releases later than 9 can be compiled with no difficulty, other than a compiler warning about the processor's source version being pegged at 9. But the warning is an obstacle if the user code is being compiled with a fail-on-warning policy, as in issue #403.This patch adopts a compromise position, and keeps track of the latest source version for which the annotation processor at least has been seen to pass the CI tests (fully understanding that such testing is no substitute for thoroughly auditing any release-to-release changes in the
javax.lang.modelAPIs and what impact they could have on the processor!). It will compute its "declared" supported source version to be the earlier ofSourceVersion.latestSupported()and that latest tested version.As a result, it should eliminate the compiler warning when running on any Java version in that range. The warning will reappear when running a compile on a later Java version, and it should be easy to alleviate that with a PL/Java release that bumps the
latest_testedversion.Merely passing the CI tests as normally run isn't enough, because the project is built with a
--release 9option. Before actually bumpinglatest_tested, a test build (at least of thepljava-examplesproject) should be done on the Java release in question and without the limiting--releaseoption.