fix: skip null returns from signal registration in AbstractUnixSysTerminal by BryanSant · Pull Request #1869 · jline/jline3 (original) (raw)

…minal

The nativeHandlers map is a ConcurrentHashMap, which rejects null values. Both TerminalProvider.registerSignal and TerminalProvider.registerDefaultSignal can legitimately return null when the requested signal name isn't valid on the host platform — SIGINFO is BSD/macOS only, and the JNI/FFM providers and the sun.misc.Signal fallback all return null on Linux.

Before this fix the bulk registration loop in the constructor (and the handle() re-register path) propagated that null into ConcurrentHashMap.put, which throws NullPointerException. TerminalBuilder catches the failure as a suppressed exception and silently falls back to DumbTerminal, leaving the caller with a dumb type and 0×0 size on every otherwise-fine Linux TTY.

Only the put is conditional; the registration call itself is unchanged, so no other behavior changes. PosixSysTerminal already uses a HashMap (which allows null values) and is unaffected.

Skipping the put is correct because nothing was actually installed — when doClose later iterates the map to unregister, there's nothing to call unregister on.