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
