<div dir="ltr"><p>Dear Panama Dev Team,</p><p>I would like to offer feedback on the current design of the <code>Arena</code> interface, specifically the decision to have <code>global()</code> and <code>ofAuto()</code> throw <code>UnsupportedOperationException</code> on <code>close()</code>.</p><p>While I understand the desire for a unified interface, I believe this design creates a significant "Refactoring Hazard" that undermines the goal of <b>Integrity by Default</b>.</p><p><b>The Path to a Leak:</b>
Most developers will naturally start with <code>global()</code> or <code>ofAuto()</code> for ease of use. Because these implementations throw an exception on <code>close()</code>, developers are actively incentivized (and practically forced) to avoid the <code>try-with-resources</code> pattern.</p><p>Later, when the developer needs to optimize and switches to <code>ofConfined()</code> or <code>ofShared()</code>, they will perform a "drop-in" replacement of the implementation. Because <code>Arena</code> is a unified interface, the code will compile perfectly. However, the developer, now conditioned to treat Arenas as managed, will likely fail to wrap the new implementation in a <code>try-with-resources</code> block.</p><p><b>The Result:</b>
A catastrophic off-heap memory leak.</p><p>In almost any other Java API, refactoring toward more manual control is guarded by the compiler or the type system. Here, the "ease of use" of a single interface effectively masks a fundamental change in lifecycle responsibility.</p><p>When dealing with <i>native memory</i>, <b>correctness and explicit lifecycle management must take precedence over interface uniformity.</b> We are trading a slightly "split" API for a very real "split" in runtime safety.</p><p>The easiest way to use an API should also be the safest way.</p><p>Respectfully and Humbly,<br>Abraham Tehrani</p></div>