JVM installs signal handlers by default

In ahnlabb/BioformatsLoader.jl#18 @timholy noted that after the JVM was initialized sending the interrupt signal (e.g. through Ctrl-C) would exit Julia. This happens because the JVM installs signal handlers by default. On a POSIX system this can be demonstrated as follows:

Normally when julia receives sigint, an exception is thrown:

julia> (() -> ccall("kill", Int, (Int, Int), 0, 2))()
Error showing value of type Int64:
ERROR: InterruptException:
Stacktrace:
  [...]

However after calling JavaCall.init() julia will instead exit:

julia> using JavaCall

julia> JavaCall.init()

julia> (() -> ccall("kill", Int, (Int, Int), 0, 2))()
0

julia> % [process exited]

The intrrupt signal (() -> ccall("kill", Int, (Int, Int), 0, 2))() can be replaced by something else that is manually interrupted by typing Ctrl-C (e.g. sleep(10)).

In ahnlabb/BioformatsLoader.jl@084efe79b7c4f9d679fcee0f44bf18c972b679b2 I fixed this by adding -Xrs to the arguments passed to JavaCall.init and adding JavaCall.destroy to the julia exit hooks.

This raises the following questions:

• Should JavaCall pass -Xrs by default?
• Does JavaCall.destroy ensure that everything is cleaned up properly?
• Do we need to use Base.disable_sigint to block interruptions and ensure JVM resources are freed when calls are interrupted?

Start by reviewing the JavaCall.init and JavaCall.destroy entry points and the JVM arguments passed during initialization. Reproduce the POSIX SIGINT behavior described in the issue, then investigate the effects of -Xrs, exit-hook cleanup, and Base.disable_sigint. Done means the project has a decided and tested policy for signal handling and JVM resource cleanup.