Should System.exit be controlled by a Scope Local?

Kasper Nielsen kasperni at gmail.com
Mon Feb 28 20:23:11 UTC 2022


Is there really a need to make this so complicated?

In all the examples I've seen so far it would be fine to set
system-exit restrictions up from the program's main class.
So why not just restrict it to the main class by default?
I assume this class is under the control of the user or
an IDE/Application Server.

Add this method to java.lang.Runtime

void restrictExit(MethodHandles.Lookup lookup, IntConsumer interceptor) {
  if (lookup.lookupClass() != "JAVA_MAIN_CLASS" ||
!lookup.hasFullPrivilegeAccess())
{
     throw new IllegalArgumentException("Invalid Lookup class");
  }
  ...
  Register interceptor to be called before System.exit
  ...
}

People could then call it, for example, from a static initializer block in
the
Main class. And use scope locals or whatever they want.

static {
  Runtime.restrictExit(MethodHandles.lookup(), ...)
}

Ideally, everyone would be using the module system, And we would have some
kind
of "application module" concept, which would be the module containing the
program's entry point. And which could have these special permissions by
default.
It might even be possible to delegate permissions to other modules if
needed.

/Kasper

On Sat, 26 Feb 2022 at 22:27, Ethan McCue <ethan at mccue.dev> wrote:

> I have a feeling this has been considered and I might just be articulating
> the obvious - but:
>
> As called out in JEP 411, one of the remaining legitimate uses of the
> Security Manager is to intercept calls to System.exit. This seems like a
> decent use case for the Scope Local mechanism.
>
>
>


More information about the core-libs-dev mailing list