JEP 411: Disable warning message with flag?

[Chapman Flack]

On 05/31/21 11:51, Mikael Sterner wrote:
> For the record, I want to point out that the latest revision to the
> JEP 411 draft didn't solve the issue highlighted below, since applications
> embedding a Java runtime still would not be able to suppress the warning
> 
> On Fri, May 21, 2021, at 19:33, Mikael Sterner wrote:
>> ...
>> I would suggest adding a flag to disable the warning message, for use 
>> in cases where an application ships to end users with a Java runtime 
>> included. Because in those cases, the warning is meant for the 
>> developer of the application and not end users. End users would not be 
>> the ones providing/upgrading the Java runtime, and in many cases it 
>> would not be acceptable to have a warning displayed on startup that 

I was just composing a message to the same effect, for a slightly different
use case.

The module I maintain for the PostgreSQL RDBMS will simply have to continue
using the deprecated API for the near future. I will need to do a minor
release that deals with the deprecation and the needed invocation flags,
and handles warning its users in a context-appropriate way that is
meaningful to them and explains how the future is going to look.

I will then need to use the time available during 17's support lifetime
to work on a heavily-reengineered major release of the module that will
meet its requirements through some other mechanism.

In the meantime, users of PostgreSQL with this module installed will
derive absolutely zero benefit from having their RDBMS logs spammed
with an obscure warning from Java that they can do nothing about
every time a DB connection loads the module.

I can suggest a couple approaches. One would be to make sure the warning
is delivered via the vfprintf hook. As I am using the invocation API to
start the JVM, I can use the hook to eat the message. This might not serve
others' needs though.

Another would be to add another -Djava.security.manager value,
allow-until-degraded. In 17, that would be treated as allow, but with
the warning suppressed. In 17+n, wherever functional degradation starts,
it should become equivalent to disallow.

In essence, if I have taken the explicit step of doing a release that
adds allow-until-degraded, that is a handoff of responsibility to me.
It is now up to me to make sure that users of this module are advised
in an appropriate way of what's going down, and it is up to me to make
sure what will happen in 17+n is reasonable (in my case, it will have to
say "can't run functions of PostgreSQL's TRUSTED variety, unless you
back up to Java < 17+n, or move to the next major version of this module").
If I don't handle that responsibility, then it just stops working in 17+n
because the flag becomes equivalent to disallow. But by using that flag,
I have clearly accepted that responsibility.

Meanwhile, users of the RDBMS don't get their logs uselessly spammed.

Another ingredient that would help is to be a little less vague about
the future "degradation", but commit to one easily-detected "degradation"
that will happen no later than any other. Maybe it could be
getSecurityManager()=null, for example, which is easier to test than
whether doPrivileged() has no ACC effect.

That way, without needing a crystal ball to know in which release 17+n
the degradation will start, I can already issue a release in advance
that will detect and handle it gracefully when it happens.

Regards,
-Chap