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

[Archie Cobbs]

I feel the need to push back a little bit against the idea-bashing here...

I completely agree that adding a new "forget" keyword to the Java language
doesn't meet the required cost/benefit standard.

However that's a separate criticism from the underlying goal, which I like
- i.e., help simplify the mental accounting that developers must juggle in
their heads.

If I am looking at a method that starts like this:

void method() {

    // Grab a highly sensitive object
    final NuclearLaunchButton btn = NuclearLaunchButton.instance();
    ...

    // Do other stuff...
    ...
}

It would be nice to know as soon as possible when "btn" is no longer going
to be used in that method.

So this is a perfectly appropriate task for IDE's or static code checkers,
e.g.:

void method() {

    // Grab a highly sensitive object
    final NuclearLaunchButton btn = NuclearLaunchButton.instance();

    // Check status
    final boolean armed = btn.isArmed();    // *@last-use(btn)*

    // Do other stuff...
}

-Archie

On Tue, Jan 27, 2026 at 10:15 AM Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

> 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 )
>>
>

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20260127/ba115c73/attachment.htm>