When sqlj.install_jar and sqlj.remove_jar execute actions in the jar's deployment descriptor, they use withJarInPath(...) to ensure that the jar in question is available on the class path of the current schema (the one at the head of search_path at the time of the call), temporarily modifying that class path if needed.

The choice of which schema's class path to subject to this treatment is itself a bit dubious, and could perhaps be another issue. It is indeed the schema that would be searched for any unqualified object names, but to the extent the jar deployment descriptor actions use qualified names, they could be referring to other schema(s) (and hence class path(s)) than this heuristic assumes. The behavior has nineteen years of history, though, and it's not obvious what other behavior would be better.

This issue pertains to an also-nineteen-year behavior, where a better way to do it is pretty clear. withJarInPath modifies the class path only if it finds the jar is not already included in the existing path. But it only checks the class path specific to the chosen schema (the one at the head of search_path).

If that schema is not the public schema, and its class path is empty, an equally old PL/Java behavior is for the class path of the public schema to be used in its place. But withJarInPath doesn't check whether the jar is on that class path. That means withJarInPath can end up creating a temporary class path for the head-of-search_path schema even when the jar in question is already included in the public schema class path. (Naturally, this situation can only arise for sqlj.remove_jar, as sqlj.install_jar is called when the jar isn't there yet.)

What's worse, withJarInPath can end up creating a temporary class path that includes only the jar in question, when the public schema class path might already include that jar and others possibly needed for the actions to succeed. Resulting failures are hard to understand, as the temporary class path is not in evidence before or after the failure.

Without tackling any broader dubious issues, at least withJarInPath should check the public schema class path when it finds a different schema's class path empty, and avoid creating a temporary class path if the needed jar already appears there.