Fix flaky FastTerminalReentrancyTest by avoiding PTY creation

[gnodet]

Summary

• Force providers("exec") in the test's TerminalBuilder configuration so JLine creates a lightweight ExternalTerminal instead of a PosixPtyTerminal via the FFM provider

Root cause

With system(false), TerminalBuilder.doBuild() enters the non-system path which ignores the dumb(true) flag and iterates FFM/JNI/exec providers. The FFM provider calls CLibrary.openpty(), creating a real PTY pair (/dev/pts/N) and a PosixPtyTerminal.

Then build() calls supportsGraphemeClusterMode() → ensureModesProbed() → probeModes() → readTerminalResponse() → readProbeChar(). This sends DECRQM/DA1 escape sequences to the PTY and reads responses via NonBlockingReader.read(timeout), which delegates to FileInputStream.read0() — a native blocking read on the PTY master fd.

Although VMIN=0, VTIME=0 terminal attributes are set before probing (which should make reads return immediately when no data is available), there is a race: on some iterations, the native read blocks indefinitely instead of respecting the timeout. Thread dump from a local reproduction:

fast-terminal-thread [RUNNABLE]
  at java.io.FileInputStream.read0(Native Method)       ← stuck in kernel read
  at java.io.FilterInputStream.read(FilterInputStream.java:71)
  at org.jline.terminal.impl.AbstractPty$1.read(AbstractPty.java:87)
  at ...NonBlockingInputStream.read(NonBlockingInputStream.java:195)
  at ...NonBlockingReader.read(NonBlockingReader.java:208)
  at ...AbstractTerminal.readProbeChar(AbstractTerminal.java:939)
  at ...AbstractTerminal.readTerminalResponse(AbstractTerminal.java:961)
  at ...AbstractTerminal.probeModes(AbstractTerminal.java:543)
  at ...AbstractTerminal.ensureModesProbed(AbstractTerminal.java:502)
  at ...AbstractTerminal.probeGraphemeClusterMode(AbstractTerminal.java:745)
  at ...AbstractTerminal.supportsGraphemeClusterMode(AbstractTerminal.java:686)
  at ...TerminalBuilder.build(TerminalBuilder.java:898)

The exec provider's ExternalTerminal avoids all of this: no PTY, no pump threads, and supportsGraphemeClusterMode() returns false without any I/O.

Failed builds: https://github.com/apache/maven/actions/runs/33349929091/job/99362003331

Test plan

• mvn test -pl impl/maven-jline -Dtest=FastTerminalReentrancyTest passes (5/5 tests, ~0.4s)
• 10 consecutive runs: 10/10 pass with the fix; 1/10 hangs without the fix
• Full impl/maven-jline module tests pass
• CI build passes

🤖 Generated with Claude Code

[gnodet]

Upstream JLine bug filed: jline/jline3#2209

The root cause is a race condition in JLine's AbstractTerminal.readProbeChar() where FileInputStream.read0() on the PTY master fd blocks indefinitely despite VMIN=0/VTIME=0 attributes being set. This PR works around it by forcing the exec provider to avoid PTY creation entirely.

[gnodet]

Well-documented fix for the flaky FastTerminalReentrancyTest. The Javadoc clearly explains the root cause (FFM provider's openpty() creates a real PTY, and the grapheme-cluster probe's native blocking read races with the timeout), and .providers("exec") is the right minimal fix to force ExternalTerminal creation.

Identical change already reviewed and approved on the 4.0.x cherry-pick (#12971). No issues found.

This review was generated by an AI agent and may contain inaccuracies. Please verify all suggestions before applying.

Claude Code on behalf of Guillaume Nodet