Fuzzy contracts are eating away your developer skills.

Older, widely used code rarely treats the Single Responsibility Principle (SRP) as a strict contract. Each method does roughly one thing, but the edge cases (nulls, mutability, memory, fallbacks) are decided case by case:

• Date / SimpleDateFormat are mutable and not thread-safe.
• List.of(...).contains(null) throws NPE.
• Collections.unmodifiableList is only a view - changes to the original list still show through.
• Integer.parseInt(null) throws NumberFormatException instead of NullPointerException.
• Arrays.sort(a, null) silently falls back to natural order.

Each exception is small, but together they mean that names can't be trusted, so every piece of documentation has to be read. Documentation stops being clarification and becomes a list of exceptions you have to remember. Newer APIs are somewhat better, but lost trust is hard to rebuild. The old warning "always read the documentation" was never about good practice - it was about code whose names could not be trusted.

Current code is easy to write and read as long as it fits conventions, but whenever something goes beyond them, we see more errors and less clear code.

Conventions become harmful when they collapse multiple domains into one while only partially handling each of them. Later, developers mistake that partial pattern for the correct model; with time and popularity, it's taken as proper design.

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

This post was rewritten to be usable as a prompt !

A design idea that reduces inheritance and boosts chainability by moving behavior into composable call chains.

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

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