Explicit end-of-use: the 'forget' keyword

[Attila Kelemen]

The "try-with-resources" is ubiquitous, and makes the code cleaner (and in
fact better due to `addSuppressed`). While this feature would end up with a
Checkstyle feature developed to disallow this (and I would turn on such a
rule). This is because this feature is to help bad code stay bad for
longer. The feature has no security benefit (despite you alluding to it),
because if people want to add a line that would end up being a security
issue, then "forget" will not stop them, because one, they can remove it,
second they can place their code before the forget (most likely). They will
not skip doing that, because they already thought it out that this is what
they want, and "forget" does not imply that anything is insecure after (a
comment is way more likely to stop something bad).

Marek Kozieł <develop4lasu at gmail.com> ezt írta (időpont: 2026. jan. 27., K,
8:35):

> To sum up, I fully agree that this is an extremely niche feature. For me
> it sits just above try-with-resources: not something you use everywhere,
> but when it fits, it removes a class of problems quite effectively. I’ve
> tried to point that out explicitly in the post.
>
> > Having references to other forums does not improve matters.
>
> Two clarifications here:
> Project Coin was a place for proposing language changes, but in practice
> most of the "chosen" features were those already prepared and feasible in
> the time frame. For many other proposals there was only brief, time boxed
> discussion, and we were explicitly asked to stop sending additional ideas.
> The fact that something didn’t make it into that one release does not mean
> it was thoroughly evaluated and rejected on principle. We’ve since seen:
> Glue classes – a more general/complex analogue of what later appeared as
> extension functions in Kotlin (introduced only a couple of years later).
> "Final interfaces" – effectively the simplified proposals that Java
> reintroduced in 2020 as sealed types.
> So there is precedent for ideas discussed back then being dropped for
> schedule/complexity reasons, then reappearing later. I reference those
> discussions to show continuity of thought, not as an argument from
> authority.
>
> Reddit references I included mainly to reduce repeated questions and give
> readers a place to see prior objections and clarifications, not as proof
> that the idea is good.
>
> I’ve been looking for areas where this idea would be especially useful,
> and it’s entirely possible that such areas are rare — or that people are
> simply not used to focusing on this kind of problem.
>
>
> > I'd kick this back to the author to gain experience in writing with the
> idioms and the spirit of the language as using block scope is a basic skill.
> That’s exactly why this concept is here: over the years I’ve found cases
> where relying only on block scope or refactoring was not ideal in practice.
>
> The "classic" example you mention is already in the post: you start with
> simple code, then later add validation, normalization, or security
> constraints. But when bug happen then choice often becomes:
> do a total refactor (new methods, extra scopes, renamed variables, more
> surface area), or do fix without any safeguard against misusing the old
> variables -  this can mean a difference of days.
> In real projects, especially under time pressure, people very often choose
> the second option. "forget" keeps diffs small, preserves history, and still
> gives a hard safety guarantee - without introducing additional risks.
>
>
>
> --
> Greetings
> Marek Kozieł ( Lasu )
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20260127/3e5d3bbe/attachment-0001.htm>