Install the SIGHUP dump handler reflectively

[holgerfriedrich]

This avoids warnings during compilation which are printed in every CI summary.
sun.misc.Signal and SignalHandler are internal proprietary APIs. The approach is taken over from Main.java.

[github-actions]

Test Results

  702 files  ±0    702 suites  ±0   1h 19m 39s ⏱️ + 2m 11s
  932 tests ±0    884 ✅ ±0   48 💤 ±0  0 ❌ ±0 
2 796 runs  ±0  2 652 ✅ ±0  144 💤 ±0  0 ❌ ±0 

Results for commit cccfa8a. ± Comparison against base commit ed4d306.

[jbonofre]

It sounds interesting, I will do the review.

[jbonofre]

This narrows the previous catch (Throwable e) to Exception. The reflective DumpHandler constructor can fail with Error subtypes rather than exceptions (ExceptionInInitializerError, NoClassDefFoundError, LinkageError). On JVMs where sun.misc.Signal resolves as a name but can't be initialized or linked (GraalVM native image, -Xrs, restricted/embedded JVMs).

Those would now escape start() and fail activation of diagnostic bundle, which is the exact "Signal not available" case this catch is meant to tolerate.

Please keep catch (Throwable e) (or catch Exception | LinkageError).

[jbonofre]

The proxy ignores method, so every call dispatched to this handler (including Object.equals/hashCode/toString) triggers a full diagnostic dump zip in the working directory.

I suggest the following guarding:

(proxy, method, args) -> {
  if ("handle".equals(method.getName())) {
    handle();
    return null;
  }
  return method.invoke(this, args); // Object methods
}

[jbonofre]

Dump.dump (collect and zip everything) runs synchronously on the JVM signal-dispatch thread here. Main.registerSignalHandler deliberately offloads its handler body to new Thread(...).

This is pre-existing behaviour, but since the method being rewritten anyway it would be a good moment to match Main and run the dump on a short-lived thread.