When PL/Java calls a user function, PL/Java's own code is removed from the protection-domain stack, so that permissions needed by the user code need only be granted to the user code, and not to PL/Java itself.

However, when PL/Java's validator loads and initializes a class to check for problems at CREATE FUNCTION time, there is PL/Java code on the stack. Therefore, if any operations in the class initializer require permissions, and are not wrapped in doPrivileged, validation will fail unless the needed permissions have been granted to PL/Java itself as well as to the user code.

Workarounds:

• User code wraps permission-requiring operations in the class initializer in doPrivileged, or
• User code moves permission-requiring operations from class initializer to the first execution of a function, or
• Permissions needed in the class initializer may be granted also to ${org.postgresql.pljava.codesource} in the policy.

When not validating, the class initializer is, of course, run on the first call of a function implemented by the class, using the access control context constructed for that function. The validator should run the class initializer in an environment constructed the same way. That would make the workaround(s) unnecessary.

A class may implement more than one function, to which different permissions could apply (for example, one with trust=SANDBOXED and one with trust=UNSANDBOXED). The permissions in effect when the class initializer runs may be those of any function implemented in the class, whichever is called first. This is unlikely to change. The class initializer, therefore, should contain only operations that will succeed in the access control context of the least-privileged functions implemented in the class. Other operations should be moved to the first execution of any function(s) with the needed permissions.