Feedback on JEP 454: The "Refactoring Hazard" of the Arena API

[Abraham Tehrani]

Dear Panama Dev Team,

I would like to offer feedback on the current design of the Arena
interface, specifically the decision to have global() and ofAuto() throw
UnsupportedOperationException on close().

While I understand the desire for a unified interface, I believe this
design creates a significant "Refactoring Hazard" that undermines the goal
of *Integrity by Default*.

*The Path to a Leak:* Most developers will naturally start with global() or
ofAuto() for ease of use. Because these implementations throw an exception
on close(), developers are actively incentivized (and practically forced)
to avoid the try-with-resources pattern.

Later, when the developer needs to optimize and switches to ofConfined() or
ofShared(), they will perform a "drop-in" replacement of the
implementation. Because Arena 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
try-with-resources block.

*The Result:* A catastrophic off-heap memory leak.

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.

When dealing with *native memory*, *correctness and explicit lifecycle
management must take precedence over interface uniformity.* We are trading
a slightly "split" API for a very real "split" in runtime safety.

The easiest way to use an API should also be the safest way.

Respectfully and Humbly,
Abraham Tehrani
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20260116/077093da/attachment.htm>