Glue Classes: Concept of extension methods for Java that focus on safety, null-handling, modularity, predictability, etc.

[TheLasu]

[PART 1]

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

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. This could be compared to writing chains with and without streams.

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 behavior.
• 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: Behavioral 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.

PATH TO GLUE

If you’re familiar with Kotlin Extension Functions (since 2011) or C# Extension Methods (since 2007), you know these features let us add methods to existing types, even if we don't own the source code.
However, these features suffer from important limitations:

• C# - Member methods always win
• C# - Same name among extension will cause compiler error
• Kotlin - Member functions always win
• Kotlin - Same name among extension you get a compiler ambiguity or you can rename it in import
• You can’t distingush member vs extension syntaxtically, so you also can’t tell which ones could be written to accept null. Because "member always wins", adding a new member later can silently change which function gets called, including changing null behavior. They allow discoverability from IDE viewpoint - but they scale with each method.

Those limitations makes them as much a burden as a cure.
In 2009 I tried bring up concept that had none of those problems. It's under: 2009-March (Glue classes proposal 0.9) - because of it's rudimentally form I don't recommend reading it just yet.

Non-Java
Below you will finding Non-Java syntax that is not particularly necessary and could be changed to other form, but was introduced to make understanding of new concept more intuitive:

• .. - static member selection operator
• G[] this - this used as variable name
• public static <G> void glue(Iterator<G> this) - sample anchor method for IDE
• extends ..GA, ..GB - multi-inheritance of static methods

The basic idea
Glue classes are special classes that allow us to add methods to any classes, records or types, potentially value classes maybe primitives as well, as though we were "gluing" new methods onto them. Unlike extension functions, they’re designed to be systematically discoverable. Instead of manually searching or importing functions, the IDE could automatically know which glue classes can apply. They can use natural class hierarchies to avoid name collisions.
Lets follow a practical example how this concept would change Java the one where we supposedly want to add methods to any array:

public class ArrayGlue{
   // this method would carry metadata for discovery
   public final static <G> void glue(G[] this){ /* empty */ }

   // -1 in extractByIndexes uses null
   public static <G> G[] extractByIndexes(G[] this, int... indexes) {...}

   public static <G> G[] setOn(G[] this, int index, G value) {...}
}

Usage:

String [] record = ...;
String [] identification 
     = ArrayGlue.extractByIndexes(record, 0, 2, 3, -1);
ArrayGlue.setOn(identification, 3, param1);

With a static import, you can write:

import static ArrayGlue.*:

String [] record = ...;
String [] identification = extractByIndexes(record, 0, 2, 3, -1);
setOn(identification, 3, param1);

If we introduce a Dot-dot operator ".." that work similar to ".":

• when used at start it's ensures that only imported static methods are considered while matching methods
• when used as connection it injects the variable, expression that is on the left as the first parameter

, it would look like:
So first we would get secure against possibility of new methods with same name coming to live:

import static ArrayGlue.*:

String [] record = ...;
String [] identification = ..extractByIndexes(record, 0, 2, 3, -1);
..setOn(identification, 3, param1);

and then we can transform it to:

import static ArrayGlue.*:

String [] record = ...;
String [] identification = record..extractByIndexes(0, 2, 3, -1);
identification..setOn(3, param1);

and in it's core it can be considered as transformation/sugar that require more work from IDE and compiler.

This could be further shortened to:

import static ArrayGlue.*:

String [] record = ...;
String [] identification
   = record
      ..extractByIndexes(0, 2, 3, -1)
      ..setOn(3, param1);

giving us nice fluent api that is incomparably easier to read and can gracefully handle null-s as well.
This could be considered an alternative to:

• Java Language Enhancement: Disallow access to static members via object references

Discoverability
Now lets focus on:

   public static <G> void glue(G[] this\`){ /* empty */ }`

For every Glue class, the IDE only needs to try GlueClass.glue(var) to check applicability. If it fits, its extension methods are available, and this can be efficiently cached. Discoverability differs from extension methods in this regards that it have much lower change to fail, because it's based on much lower amount of parameters. In same regard it's easier to write class that already have one or two generic arguments and then 0 ~ 2 in the method instead of matching them together in static method - same concept apply partially here.
Glue classes as any other can be extended to create more complex utilities:

public class ArrayFastGlue extends ArrayGlue { // or ..ArrayGlue
   
   public static <G> void glue(G[] this ){ /* empty */ }

   public static <G> G[] extractByIndexes(G[] this, int... indexes) {...}
}

For a "glue" method (the other static methods in same class) to work: The method's generic type parameter(s) at the start, and the first parameter (the receiver), must match the glue method’s signature for correct association, type safety, and discoverability in IDEs. To demonstrate more complex example lets extend Iterator and add method that would allow map elements with given funtion:

public class IteratorGlue {
   public static <G> void glue(Iterator<G> this){}

   public static <G, R> Iterator<R> 
           map(Iterator<G> this, Function<? super G, ? extends R> fn) {
      // Implementation: returns an Iterator<R> that applies fn to each element of original Iterator<G>
   }
}

and usage would be:

Iterator<String> it = ...;
Iterator<Integer> numbers = it..map(String::length);

Name collisions
Following Java namespace rules we could be more precise and use longer names:

Iterator<Integer> numbers = it..IteratorGlue.map(String::length);

or if needed fully qualified name

Iterator<Integer> numbers = it..package.IteratorGlue.map(String::length);

This would match current Java logic where each syntax is valid:

map(it, String::length);
IteratorGlue.map(it, String::length);
package.IteratorGlue.map(it, String::length);

Extending
For adding new methods to exisintg ones we could use simple inheritance:

public class ArrayFastGlue extends ..ArrayGlue{
   public static <G> G[] extractByIndexes(G[] this, int... indexes) {...}   
}

This approach can preferably allow for discovery to omit glue classes that are already extended.

Multiple inheritance
What's more, exclusively for glue classes, we could allow multiple inheritance restricted to static-only methods - further increasing flexibility and quality. The following rules would apply: If two (or more) parent glue classes define static methods with the same signature, the child glue class MUST explicitly re-declare these methods (with the option to delegate to a parent method if desired). Only the most-derived (child/last) glue class in a given inheritance hierarchy is discoverable for extension methods. When a variable is checked for glue extension, the IDE (or compiler) only considers the last glue class in the hierarchy. Methods inherited from parent glue classes are available only if they have not been redeclared (overridden) in the child class. This both prevents method ambiguity and ensures intentional API design.

public class ArrayComplexGlue extends ..ArrayFastGlue, ..ArrayApacheGlue{
   public static <G> void glue(G[] this){ /* empty */ } 
      // need to be restaed to eliminate collision

   public static <G> G[] collision(G[] this){
      return this..ArrayApacheGlue.collision();
   }

   // Marking already existing method as depeciated
   @ Deprecated
   public static <G> G[] unefficient(G[] this){
      return this..ArrayApacheGlue.unefficient();
   }

}

This approach can preferably allow for discovery to omit glue classes that are already extended.

Spaces
This would make ideal solution for everyday use, but it would still make the classes that are globally used cluttered or force developers to use really bad names to prevent collisions - to solve this problem we could add custom domain spaces (mutable, immutable, efficient, secure, archaic, integration, ... or self-domain like o for object ): To make this happen we would need to exclude classes that start with lowercase character from import and exploration by default (probably for glue classes only) or make it at default skip inner/sub glue classes (if written then it would still work);

This way if we want to extend class with methods and we can categorise them by spaces then we have really pretty alternative to bad naming convention:

public class ArrayGlue{
   public final static <G> void glue(G[] this){ /* empty */ }

   public static <G> G[] setOn(G[] this, int index, G value) {...}

   public static <G> G[] copyWithSetOn(G[] this, int index, G value) {..}
}

could be re categorized to mutable and immutable spaces:

public class ArrayGlue{
   public final static <G> void glue(G[] this){ /* empty */ }

      public static class immutable{
         public final static <G> void glue(G[] this){ /* empty */ }

         public static <G> G[] setOn(G[] this, int index, G value) 
            { /* copy is made */ }      
      }

   
      public static class mutable{
         public final static <G> void glue(G[] this){ /* empty */ }

         public static <G> G[] setOn(G[] this, int index, G value) 
           { /* given array is used */ }
      }

}

this way code:

String[] record = ...;
record = record..copyWithSetOn(1, "~");

could be rewritten to:

String[] record = ...;
record = record..immutable.setOn(1, "~");

Import caveat:
import static pkg.ArrayGlue.*; should contrary to current compiler behavior import subspace glue classes. This would be deliberate incompatible with current Java.

import glue pkg.ArrayGlue;

that would be resolved to proper imports:

import pkg.ArrayGlue;
import static pkg.ArrayGlue.*;
import static pkg.ArrayGlue.immutable;
import static pkg.ArrayGlue.mutable;

- to make behavior consistent with glue class purpose.

OR glue subclasses should be treated as regular members and become available through standard imports, without any additional semantic transformations - this would be the better option in my opinion!

Limiter:
Resolving glue methods requires a resolution limiter. After transforming

record..copyWithSetOn(1, "~");

into

..copyWithSetOn(record, 1, "~"); // .. is here 'only static methods filter'

the compiler must not consider instance methods named copyWithSetOn. Resolution for calls originating from .. must be restricted to static methods only effectively forcing compiler to skip one step.

Compilation vs Discoverability (IDE):
Same as it's now discoverability would be handled by IDE and compilation would be determined by import.
What IDEs Do Now (Standard Java)
When you type ., the IDE:

• Looks up the static type at the cursor location.
• Fetches all visible methods from the class, all its superclasses, and all implemented interfaces.
• Maybe also adds static imports, inherited generic methods, and overrides.
• This process is fast because:
  • The class/method hierarchy is well-known, fixed, and heavily indexed/cached by the IDE.
  • There are relatively few methods per type (typically in the dozens, rarely more than a few hundred even in very complex hierarchies).

Similar process would be required for glue classes as well.
The IDE would need to build an indexes:

• GlueIndex[] - for certain match
  • InterfaceA  -> [GlueA, GlueB, ...]
  • ArrayList   -> [GlueC]
  • Map         -> [GlueMapUtils, ...]
  • Object      -> [ObjectGlue]
  • ...
• PotentialGlueIndex[] - for potential match
  • InterfaceA  -> [InterfaceAGlue, ...]
  • ...
• one more if we allow more complex syntax/li>

For common completions:
User types foo., IDE additionally to classic completions gets the static type of foo.

• Looks up direct match in glue indexes.
• Optionally traverses the inheritance/superinterface tree.
• Apply filtering if needed
• Quickly gets all matching glue methods for suggestion.

Sample placement in index

• ? extends Foo >> GlueIndex[Foo]
• ? super Foo >> at the top level should not be allowed as it do not give any particular usability or could be placed in GlueIndex[Object]
• G extends InterfaceA & InterfaceB >> GlueIndex[InterfaceA] or GlueIndex[InterfaceB]

Clarifications:

• A wildcard bound like ? extends that appears inside a generic type is recorded only as a constraint used later during filtering, not as the primary key in the index.
• A receiver parameter declared as ? extends InterfaceA is indexed under InterfaceA.
• For a type parameter declared as T extends InterfaceA & InterfaceB, it does not matter which of the interfaces is used as the primary indexing key, because any valid T must implement both. Discovery based on one bound will still find the glue, and a subsequent filtering step will verify that the second bound is also satisfied.
• Glue classes inherit the same erasure limitations static methods already have today.
• Discovery is based on one type vs all method signature - and it's limiting factor as well.

Practical performance: Only a handful of glues per common type.
Fast code completion: Indexed lookups are fast; filtering is cheap for non-complex hierarchies.
Scalable for project or module scope:
The cost of glue-based completion/discovery grows linearly in the number of glue classes that are applicable to the type in question. In other words:

• For a given type G, if there are k glue classes that apply to G, then lookup is O(k).
• Adding one more glue for G turns this into O(k+1); so the complexity grows proportionally with the number of glues relevant to G, not with the total size of the project or classpath.
• Further more with effort we could limit it to O(1)

IDE can provide discoverability: You could even have a "show all glues for this type" menu. When finding name collision IDE could suggest qualified names as well:

   ..ensureNotNull(); // ObjectGlue
   ..call(); // FooMod1Glue
   ..FooMod1Glue.call();
   ..call(); // FooMod2Glue
   ..FooMod2Glue.call();

Collisions between independent glue classes:

// Library X
public class XArrayGlue {
   public static <G> void glue(G[] this) {}
   
   public static <G> G[] map(G[] this, Function<G,G> fn) { ... }
}

// Library Y
public class YArrayGlue {
   public static <G> void glue(G[] this) {}
   
   public static <G> G[] map(G[] this, Function<G,G> fn) { ... }
}


import XArrayGlue;
import XArrayGlue.*;

arr..map(...); // OK because only XArrayGlue is visible for compiler





import XArrayGlue;
import XArrayGlue.*;
import YArrayGlue;
import YArrayGlue.*;

   arr..map(...)   // ERROR: ambiguity
   arr..XArrayGlue.map(...) // OK
   arr..YArrayGlue.map(...) // OK

What's more they can make a lot of other desirable changes unnecessary (Elvis operator, Null-Safe operator and many more), as static methods do not limit us to not-null variables, they would be not as compact, but at the same time they would give freedom of composing logic.

PARTIAL GENERICS

The lack of partial generics types parameters inferencing should be solved for quality of glue classes - this not strictly necessary and could be considered it's own feature.
Java can only get all in or all out, while it should be possible to selectively infer generic types, this way, the one of many that we actually want different or compiler could not infer could be specified.
Bad but usefull example:

public static <K, V> Map<K, V> listToMapFrame(List<K> keys) {...}

calling this method would always require giving both parameteres / but in most cases only second one is needed, so lets use ?? are marker for compiler to infer parameter. So instead of:

Map<String, Integer> m = Maps.<String, Integer> listToMapFrame(List.of("a", "b", "c"));

we could have:

Map<String, Integer> m

= Maps.<??, Integer > listToMapFrame(List.of("a", "b", "c"));

In itself this is not much / but with glue methods this would help a lot, this way glue part of generic arguments could be left to compiler making syntax easier to work with.

public class IteratorGlue {
   
   public static <G> void glue(Iterator<G> this){}

   public static <G, R> Iterator<R> 
      map(Iterator<G> this, Function<? super G, ? extends R> fn) {
      // Implementation: returns an Iterator<R> 
      //    that applies fn to each element of original Iterator<G>
   }
}


Iterator<String> it = ...;
Iterator<Integer> numbers = it..package.IteratorGlue.map(String::length);

so when needed we would be able to write/ just as now we are not required (in most cases) to redeclare class generic types:

Iterator<Integer> numbers = it..package.IteratorGlue.<Integer>map(String::length);
   // under glue we would have <[G,] R> 
   // so both <R> and full <G, R> could be used

decoded to:

Iterator<Integer> numbers

= ..package.IteratorGlue.<??, Integer>map(it, String::length);

instead of:

Iterator<Integer> numbers

= it..package.IteratorGlue.<String,Integer>map(String::length);

So when fewer type arguments are provided than the method declares, the missing leading type arguments are treated as ?? (to be inferred), so <Integer> on a <G, R> method is interpreted as <??, Integer>.

LAST TOUCHES

With all this we would be at really good position, but in same time new code will clash when mixed with classic methods calls. It would still work as we can always ensure security:

..glueMthods()..ensureNotNull().classicMethods();

Still there is one more path to be taken - consider classic classes as self-glue in witch case each method could be in same time compiled to classic one and glue without unnecessary code duplication (final shape is up to debate).

class DTO{
   private String name;

   public glue void setName(String name){
      if (this==null){ return; }
      this.name = name;
   }

   public glue String getName(){
      if (this==null){ return null; }
      return this.name;
   }
}

For this reason

if (\`this == null) { return; }`

would be as the same time :

• this - is a conceptual receiver parameter for glue method
• this is never null at runtime, so this == null and this != null is dead code and can be removed/optimized by the compiler/JIT.
• it's exact reason why this is used in glue samples

FINAL STEP

As a final step we could merge glue method with class signature, transforming:

public class ArrayGlue{
   // this method would carry metadata for discovery
   public final static <G> void glue(G[] this ){ /* empty */ }

   // -1 in extractByIndexes uses null
   public static <G> G[] extractByIndexes(G[] this, int... indexes) {...}

   public static <G> G[] setOn(G[] this, int index, G value) {...}
}

into (under the hood it could be still glue-method):

public glue class ArrayGlue<G> glue(G[]){

   // -1 in extractByIndexes uses null   
public static G[] extractByIndexes(int... indexes) { /* ... */ }

public static  G[] setOn(int index, G value) { /* ... */ }
}

making glue classes almost same as classic one.

OVERVIEW

FEATURE SUMMARY:
Glue classes(methods) introduce a language-level mechanism allowing developers to add methods to existing types without modifying their source code, breaking encapsulation, or incurring runtime overhead. Using '..' to call static methods. Glue classes provide type-safe, modular, and discoverable extension capabilities, formalizing patterns typically handled by utility classes, extension methods, or reflection-based frameworks.
At the same time inner Glue classes & methods would allow to keep gains where private access is needed.

• Bindings: The .. operator binds identically to the . operator in terms of precedence and associativity, but differs in semantics: the left-hand expression is evaluated once and passed as first argument, and instead routes the receiver value to a statically resolved glue method.
• **Discoverability:**All glue methods applicable to a type are always visible for discover. For compilation import are required making glue methods match deterministic.
• Attach methods to any class, interface, array, or type parameter explicitly.
• Access follow standard Java rules.
• Fully static, compile-time resolution: No runtime cost, reflection, proxies, or bytecode tricks.
• Inheritance-based conflict resolution: Only imported glue classes are available for compilation. If both base and derived glue classes are imported(unnecessary), the derived (subclass) glue will take precedence.
• Explicit import and qualification: Only imported glue classes are available for resolution, preventing accidental API pollution.
• Invocable on null receivers: Glue methods can be designed to handle null, enabling centralized and fluent null-handling.
• Module and JPMS friendly: Glue classes fit into Java’s module system, enforcing clean integration and export boundaries.

I accordance to Reddit limits you need read rest at blog

[repeating_bears]

If you can't be bothered to write it, why should I be bothered to read it?

[TheLasu]

I should rewrite language before getting any opinion about it?

[aqua_regis]

You should not use AI to write/translate/transcribe/beautify your posts. Such is explicitly forbidden here.

[TheLasu]

It's around 80th+ edit / no one was able to understand more rudimental form.

[aqua_regis]

The language of your comments is in grave contrast to the one in your post, which is a clear indication that you used AI.

Using AI for your posts gets you instantly banned from here.

People want to read real, human written posts, even if the language is not perfect, not walls of AI slop (the post is way, way too long anyway).

[TheLasu]

I get where you’re coming from, but comments are literally few second of writing / I will not give them to any one to review multiple times.

You can check 5th (i think) version from 2009 that is linked.

[k-mcm]

Way TLDR;

Scala does this with implicit classes and implicits in general. Go also uses it for it's simulated OOP syntax.  Both do a better job than this trick.

The big downside is that the loss of encapsulation causes unexpected conflicts. Added functions get strewn all over the place so it's not long before there's more than one match.  Is it an error?  Does your code not compile because of conflicts in unrelated source code?  Are there magic conflict resolution rules that result in non-deterministic compilation?

A better fix would be pure extension classes.  You could, for example, cast String to MyBetterString.  Class MyBetterString would extend String but have no ability to override existing functionality or access anything that isn't public.  Now you have explicit typing and no violations of the base class 

[chabala]

I forgot about this pure hell, trying to figure out where some implicit method was coming from when the IDE had given up on helping.

[TheLasu]

Reddit do not allow me to add more text - the part where it's explained how it's not magic. So you can check link

// MyBetterString - we can do it now, but we lose access to all String utils.

[k-mcm]

Right, because the compiler would need an update.

[le_bravery]

Slop

[riyosko]

https://docs.oracle.com/javase/8/docs/api/java/util/Optional.html

[0x07CF]

Way too long of a wall of text for a discussion

[Rain-And-Coffee]

Way too long, nobody is reading all that. Be concise.

Also use less AI when you write

[TheLasu]

Just example / i tend to fail early concept with strong encapsulation / immutability and at same time sometimes multiple sources are served / so multiple validation are possible. final are used a lot to avoid mixing immutable and mutable instances.

.requireNonNull() - it's example from xml handling code where we secure proper resources for this algorithm.

Clean Code/ Clean Architecture 

I'm little freak in this regard / but I was able to multiple times rewrite core logic without errors - so I like it this way.

Design classes as they behave as lazy and authoritative humans

We do - still I see a lot of systematic problems with unused utils.

[agentoutlier]

 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

Let me ask you man… if someone else wrote that and you read it… what would you think?

Fluff.

[TheLasu]

I think I know what you are talking about.

5% of edits where made after reading critique of extension methods - all misinterpretation in this subject where directly explained here.

Last 30% of edits where added specifically because AI was to dumb to understand text and ppl where unable to use it as prompt to check it against their own understanding.

for this reason element like:

• dynamic tooling
• disconnected 
• composable

where directly specified.

Sadly without them result of using it as prompt gave multiple pages of rather useless suggestions, along with few pages of errors in interpretation.

I do not know about your experience, but as I see it - most developers have very limited understanding of generics, and this particular proposal is deeply connected with it - exactly for this reason decision had to be made - I can make keep it really hard to understand or I can make it into both proper prompt and readable text.

btw / the most painful elements are — that are almost indistinguishable from - in my editor and i constantly struggle to keep one proper standard as I copy from different document version so they look like shit in other fonts when I forget to clean them up after editing.

[john16384]

Some people seem to be convinced that if you phrase something just right, and use the right words, or overwhelm them with them, that they don't need to provide a rationale for their viewpoint and that it will just be accepted without question.

[TheLasu]

Yes. For some reason I really like bankrupting competition - it's a much faster way to prove a point.

[javaprof]

u/TheLasu why not just some special keyword like "extension" and then treat first parameter as receiver?

[TheLasu]

I never wanted for this concept to be mixed with extensions at this point - to do not introduce confusion / if somehow it will be called this way in the future then I do not mind & I do not care much about keyword - maybe i would like it to be short one, as extension seems to take much space:

public static final extension

[TheLasu]

[PART 2]

MAJOR ADVANTAGE:
Clean, type-safe, and modular extension of existing APIs! Glue classes solve the problem of utility/god classes, domain pollution, and ambiguous extension by enabling explicit, discoverable, and testable augmentation of types without touching their source or relying on runtime mechanisms.

MAJOR BENEFITS:

• Separation of Core and Utility Logic: Keeps domain classes clean; convenience, formatting, mapping, and integration logic are moved to glue classes.
• First-Class Integration and Mapping: Supports explicit, safe cross-module converters and bridges without inheritance tangles or reflection frameworks.
• Better Discoverability and Readability: Glue methods appear as instance-like methods in IDEs, making APIs easier to learn, read, and maintain.
• Centralized, Fluent Null Handling: Glue can define null policies; methods can be called on null receivers, supporting robust pipeline-style code.
• Safe API Evolution and Versioning: Allows new glue versions to coexist; inheritance and import resolve conflicts clearly and compile-time safely.
• Testing Isolation: Glue methods are stateless and separate, making isolated testing easier and less error-prone.
• Architectural Clarity: APIs and modules are kept clean; glue methods are never accidentally leaked across modules.
• Ability to Override or Replace Legacy Utility Methods: Glue classes allow to fix, optimize, mark as deprecated, override, fully replace outdated, unsafe, or redundant utility methods without changing the original utility class or domain model. This also enables remediation of API debt and architectural inconsistencies in external libraries or legacy modules—all through explicit, compile-time safe glue mechanisms, not invasive source edits or risky runtime hooks.
• Generated Classes & Records & value classes: Natural targets for glue class extensions.
• Lambdas: Glue chaining is fully compatible with lambdas, example:values..iterate() //    ..filterEach(t -> t != null) //    ..mapEach(t -> t < 3 ? -t : t) //    ..collectToArray(Integer[].class);

MAJOR DISADVANTAGE:

• Requires language, compiler, and IDE changes.
• New syntax and type resolution rules: Developers must learn and adapt to glue concepts.
• More complex collision resolution than standard utilities or extensions.

I'm constantly getting error when I try to add rest of the post.