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.

If (false) may be useful

Can you be friend with this kind of dead code? In this particular subject my opinion is slightly different from the general. I can agree that in the ideal programming world there is no need to use dead code, but in reality there are situations when it's good to consider this solution as appropriate.

Secret behind 0.999... = 1

« Polska wersja »

Wikipedia: 0.999...

Searching a solution we often forget about the problem behind it. I'm familiar with the wrong focusing on 'how' instead on 'why', and what's more I've seen people doing the same mistakes as well. For example, let's just look at law regulations as synonym of complication paired with uncleanness. However, I'll drop that subject and introduce the similar problem occurring in maths. Do not expect any great proof, because I'll do that to explain it as simple as possible.

Przeglądarki kontra bezpieczeństwo

Czyż Internet Explorer nie służy do przeglądania internetu z twojego komputera i vice versa?

Mogliśmy jakiś czas temu zaobserwować miły gest ze strony Mozilli wspierający osoby które chcą zwiększyć bezpieczeństwo ich produktu (patrz: Refresh of the Mozilla Security Bug Bounty Program). Zaciekawiony tymże faktem poszperałem więcej w poszukiwaniu informacji o bezpieczeństwie naszych przeglądarek...

Ciekawostką jest raport firmy CERT z 2005r (ich pierwszy nawiasem mówiąc) - jednakże jego jakość jest wątpliwa i bardziej tu pasuje nazwa 'zestawienie'. Taki współczynnik jak ( Liczba luk / Popularność ) jest nie tyle nietrafiony co wręcz błędny. Otóż im większa szansa zysku z odkrytej luki tym częściej i szybciej zostanie ona wykorzystana, a w internecie ilość przekłada się przecież w bezpośredni sposób na zysk. Tak więc, moim zdaniem, powinno być raczej ( Liczba luk * Popularność ). Ten sam mechanizm działa też w drugą stronę: firmy mające małą liczbę użytkowników są znacznie mniej podatne na ataki.

Informatyk zawodem wysokiego ryzyka?

Kolejny post dotyczący naszego Polskiego "zaścianka". A mianowicie chciałbym napomknąć jak wygląda egzystencja nas informatyków w kontekście przepisów prawnych oraz strachu przed naszymi umiejętnościami.

Javarsovia 2010 z drugiej ręki

Odczucia

• Z niecierpliwością czekam na następną Javarsovie, co moim zdaniem samo z siebie świadczy o tym jak bardzo byłem zadowolony z uczestnictwa.
• Afterparty także pobiło moje oczekiwania, tylko prelegentów na niej trochę brakowało.
• Dodatkowo byłem pod wrażeniem liczby uczestników.
• Na pewno niewybaczalnym jest fakt, że nie wygrałem Asusa.
• Tak wiele się działo, że brakowało mi czasu, aby dokładnie zapoznać się ze stoiskami sponsorów.

GUI in GridBagLayout

Basically, I do not like GridBagLayaout, but from my point of view it's the most effective way to build and maintain GUI. So before explaining my point of view, let's eliminate other path.

Forwarding exceptions as language potential

Each of Java programmer knows how exhausting a handing exception can be. So sooner on later he/she founds the situation when he/she exactly knows that he/she is handling the exception that will never occur. Some thoughts about this can be found here.

The '!' logical-complement operator (fixed)

It's high time to clear doubts about: The '!' logical-complement operator. With little help of someone who can express himself more clearly, subject should be easier to follow.

Some time ago I used to know all operators priorities in C++, using a minimal number of braces resulted with a quite compact code in logical cases. It was really easy to read that again, but only for me, what I did not see as a problem. When I started to work on the same code with others there were no turn back and I had to make conditions more readable...

The logical-complement operator !

Maybe I'm weird but I really do not like syntax for this operator.

Now time it's like:

if (!person.getThinkingModel().isThinking()){...}

I would personally prefer:

if (person.getThinkingModel().!isThinking()){...}

I would do same about instanceof to allow:

if (obj !instanceof Person){...}

Work around:
Would be nice to see both methods generated isThinking() as well as isNotThinking() instead of one in that case. Problem in this solutions involve setters which should be duplicated as well, and mostly 'Not' version should call traditional with simple negation, which increases stack traces.

if (person.getThinkingModel().isNotThinking()){...}

This way have one more advantage. When you write in more than one language you can worry less about operators priority.

Use yours own judgement, which is easier to read and write.

Little confusion about Generics

Lets consider some class used for collecting References. It requires little work but there is way to do not determine Reference type to early. So lets observe consequences of this action.

import java.lang.ref.Reference;
import java.lang.ref.WeakReference;

/**
 * Collects {@link Reference}-s
 */
public class ReferenceCollector<Ref extends Reference</* ? extends */ Type>, Type>
    implements Iterable<Reference<? extends Type>> { ... }


This class will allow given code to compile:

ReferenceCollector<WeakReference<String>, ?> rc1 = null;

ReferenceCollector<WeakReference<String>, ? extends Object> rc2 = null;

On the other hand reversing Type arguments will be not allowed:

ReferenceCollector<WeakReference<? extends Object>, String> rc2 = null;

This mean that nesting is count more then arguments order, what more it's all about compatibility not as I would expect equality of types. Probably I just need read rest of JLS when I'll have free time to get idea why '?' is allowed as second generic argument.

I just killed Eclipse

I like enum-s more than most people do.

They are really nice to use and synchronization-safe. But as I found, they have their limits as well.

After generating 1,8Mb Java code for one enum Eclipse dying after most try of refactorization ;), Java was not happy at all about it as well with error:

The code for the static initializer is exceeding the 65535 bytes limit

Enhanced while statement proposal

OVERVIEW

FEATURE SUMMARY:
Enhanced while statement allow to iterate through iterator.

MAJOR ADVANTAGE:
People will stop working around for-each loop.

MAJOR BENEFIT(s):
Allow to easy express operation on iterator(s), and iterating over non linear Iterators.

MAJOR DISADVANTAGE:
Automatic loop over Iterator my be problem for some peoples.

ALTERNATIVES:
Using while loop.

'forget' keyword proposal

2026 version

OVERVIEW

FEATURE SUMMARY:
'forget' keyword allows to erase variable from current context, or it means that field should not be used.

MAJOR ADVANTAGE:
This change makes language be more WYSIWYG.

MAJOR BENEFIT(s):

• It makes people be able to erase 'variable' from current context, while now it's:
  • impossible for final variables (only by comments),
  • impossible for arguments (for not final Object we can assign null),
  • impossible for fields.
  • local fields need more or 'less' artificial blocks (two lines wasted and one indent level).
• Declaring that variable should not be used, or does not contain valid information for this scope (at current time) will be possible.
• Code quality does not fall so drastically after we leave it, comparing to '=null', 'only comments' or 'weird blocks'.

MAJOR DISADVANTAGE:
New keyword == Someone can have declared method/field/variable named 'forget'.

ALTERNATIVES:
It's already listed.

'final' without explicit type proposal

OVERVIEW

FEATURE SUMMARY:

MAJOR ADVANTAGE:
It allows people to concentrate on logic during operating on heavy generics and to use values which are more intuitive for them than variables.

MAJOR BENEFIT(s):

• It allows to avoid duplicating unnecessarily types of declaration.
• It increase a concentration on 'what I've got' than on 'what type is that' (we decrease size by one to obtain last element index, not because we can do this = it's int), while for variables we still keep concentrate on: 'what type is that' / 'what I can put there'.
• Editing existing code to get some value from method chain is easier.
• That method can be itself multi-thread with this, but it's a far future.
• Using of Generics is easier.

MAJOR DISADVANTAGE:

• Certainly, some people will overuse this solution.
• Consider operator is easier to read.
• It might be a problem if a person does not know how to give proper names for values.

ALTERNATIVES:
Normal variables.

Glue classes proposal 0.9

OVERVIEW

FEATURE SUMMARY:

Glue classes allow to link utils direct with objects.

MAJOR ADVANTAGE:

Forgotten functionality can be not such big deal now.

MAJOR BENEFIT(s):

• New functions can be easy localized (critically important while introduce new peoples into project).
• Security: glue class do not see anything protected.
• Light binding new functions with existing classes.
• Number of used classes reduction.
• Allow to assign methods and functions(static methods) to arrays, classes, interfaces, …
• It's proof against same method occurs in class and delegator as well like in two delegators.
• Allow to link gained(.jar) logic with new one, witch is impossible before final developer implements his classes.
• Allow to project compact interfaces and do not worry about additional logic.

MAJOR DISADVANTAGE:
Do not know any ;) sorry.

ALTERNATIVES:
Utils classes, more work on project, duplicated code...

Return 'this' proposal

GENESIS

It's a simplified 'This' type problem, which seems to be too much complicated as for now and need more analyses. Construction is designed not to interact with possibility that 'This' type will be introduced.

OVERVIEW

FEATURE SUMMARY:
It allows the method to return reference to 'this' object.

MAJOR ADVANTAGE:
Simplification of return this; statement.
'void' can be easy replaced with 'this'.

MAJOR BENEFIT(s): It would prevent NullPointerException, and make some 'builder' like interfaces look really clear and simple.

MAJOR DISADVANTAGE:
Returned value cannot be changed while inheritance.

ALTERNATIVES:
Self-bounded generics, This type.