In 2009, Final Interfaces were a concept, and many years later Java got Sealed Types

When working on submissions for Projects coin - Controlled Inheritance was one element that I wanted to have.
Sadly, we where told to not push forward any heavy changes into Java - this way idea of limiting inheritance was reduced to making inheritance scope of interfaces final.
Then it turned out that there was 0% chance that any change requiring extended consulations would make it - basically already prepared/aproved projects will be selected.

I have to admit that final is not the best word for this purpose and sealed is definetelly better pick.
I still have my draft of the: Final interfaces... proposal so it can be compared:

interface final Interface allow ClassI

vs

sealed interface Service permits Car, Truck

Earlier, consideration across language was between final and scope limitation - not really secure enough solution for me.

I'm really curious whether Java’s sealed types are a direct evolution of the ideas behind "final interfaces", or if they emerged independently.

WORKAROUNDS

Coding Style: Formatter barrier

FORMATTER BARRIER

Trailing line comment (//) can be used as a formater barrier to prevent automated formaters or IDEs from collapsing or reflowing long fluent chains. This convention has been used successfully in production codebases for more than decade, including in large and continuously evolving systems, without causing semantic issues or tooling problems. Its primary benefit is preserving the visual structure of code across edits and refactoring, which significantly improves readability, code review quality, and long-term maintainability; it also helps reviewers more easily identify flawed logic or misunderstandings during code review. Maintaining a stable visual layout supports developers (especially those who rely on visual patterns when reading and reasoning about code) in recognizing intent, spotting inconsistencies, and retaining structural understanding even after substantial changes. This practice affects only formatting, has no impact on compilation or runtime behavior.
Tools already treats comments as layout anchors!

Just compare:

public static <D extends IcdCodeGet & Comparable<D>, L extends IcdListAccess & Comparable<L>> IcdCodeGet[] getBestCodes( //
      ComparableList<ComparableLink<L, IcdCodeGet[]>> bests //
      , L list //
      , boolean renew //
      , ExtendedIterator<CounterCmp<D>> statsSource) {...}

with:

public static <D extends IcdCodeGet & Comparable<D>, L extends IcdListAccess & Comparable<L>> IcdCodeGet[] getBestCodes( ComparableList<ComparableLink<L, IcdCodeGet[]>> bests, L list, boolean renew, ExtendedIterator<CounterCmp<D>> statsSource) {...}

This gives us freedom to auto colapse arguments and uncollapse them manually when needed.

Java Proposal: The Glue Classes - Explicit, Modular Type Extension

Sample code:

   Objects.requireNonNull(some);
   final A a = some.getA();
   Objects.requireNonNull(a, "explanation");
   validate(a);
   final B b = a.getB();
   Objects.requireNonNull(b, "explanation");
   b.process(param1);


Same code written using glue:

   some..ensureNotNull()//
      .getA()..ensureNotNull("explanation")..ensureValid()//
      .getB()..ensureNotNull("explanation")..process(param1..ensureNotNull()); -- easy


MOTIVATION

We made great success moving to OO, sadly we are only quarter of the road there.

Why Glue Beat Static Utilities in Real-World Codebases:
While many of the core benefits of glue classes (such as method attachment, composability, and disciplined null handling) could be simulated with static utility methods — the practical outcome is fundamentally different and hard to compare with glue classes.

Experience with External Libraries
Most code bases I've used (and contributed to) are full of sprawling utility modules, overloaded with:

• Configurable options and sys-opts
• Redundant null-checking and validation
• A continuous tension between usability and maximum usable decomposition

This leads to code that is either unreadably cryptic or so decomposed that developers struggle to discover, connect, or reason about intent.

Static Methods: Limitations

• Decomposition makes compact APIs hard to discover:
  Static methods live outside the type they operate on. Even with clever tags or code-rewriting, you can't naturally find, autocomplete, or chain them as you would with instance (or "glue") methods.
• Responsibility separation increases friction:
  The more you split up code as recommended ("don't pollute domain objects, keep util logic separate"), the less obvious it is to the next developer where to look for required behaviour.
• Null-handling becomes boilerplate:
  The majority of library util methods guard against null upfront—resulting in repeated validation, fat method signatures, or the spread of verbose Optional-driven patterns(force us to rewrite known code just for null from time to time).

Why Glue Classes Are Fruitful

• Discoverability and fluency:
  By attaching methods as views directly to types, glue classes make contextually appropriate utilities instantly available and visible right where they're needed.
• Controlled extension and evolution:
  Behavioural changes, versioning, and testing remain isolated and explicit; you can swap, layer, or upgrade glue classes without altering core types or writing brittle adapters, I would compare it to default methods that are not limited by class ownership and not-null state.
• Centralized, composable null policies:
  You can bake robust, contextual null-handling exactly once, in glue, and chain safely—even for null receivers. This way code could be decomposed without negative consequences.
• Cleaner architecture without trade-off:
  Code remains decomposed, modular, and maintainable, yet the surface API is obvious — giving the best of both worlds.

Summary
While static utilities, annotations, and dynamic tooling can go a long way to simulate some extension patterns, only glue classes offer a truly fruitful, disciplined, and developer-friendly solution for modular extension, composable integration, and safe evolution—unlocking readable, discoverable, and maintainable APIs at scale that would work for multiple disconnected teams - basically you can see it as Kotlin’s extension functions on steroids.

Java: Enhancing Scope Safety: The forget Keyword

Reddit discussion »

OVERVIEW

FEATURE SUMMARY:
The forget keyword prevents further access to a variable, parameter, or field within a defined scope, attempts to access the variable in forbiden scope will result in a compile-time error.

MAJOR ADVANTAGE:
This change makes variable and resource lifetimes explicit and compiler-enforced, improving code clarity and predictability.

MAJOR BENEFITS:

• Allows explicitly removing a variable from the active context (in terms of accessibility), which is currently:
  • impossible for final variables (only comments can be used),
  • impossible for method parameters (except assigning null to non-final references),
  • impossible for fields,
  • cumbersome for local variables, requiring artificial blocks (extra lines and indentation).
• Makes it possible to explicitly declare that a variable should no longer be used or no longer represents valid data in the current scope.
• Preserves code quality over time, avoiding degradation caused by = null assignments, comments-only conventions, or artificial scoping blocks.

MAJOR DISADVANTAGE:
The introduction of a new reserved keyword introduces potential source incompatibilities with existing codebases that define identifiers named forget.

ALTERNATIVES:
Java currently provides only scope-based lifetime control (blocks and try-with-resources). It lacks a general, explicit, and compiler-enforced mechanism to terminate variable usability at an arbitrary point within an existing scope.