Working with old Java code can sometimes feel like trying to read a book where every sentence is three times longer than it needs to be. You find yourself wading through lines and lines of repetitive statements, clunky checks, and patterns that just feel outdated. It gets the job done, but it’s not a pleasant experience to read or maintain.
I’ve spent a lot of time in these codebases. The good news is that modern Java, from version 8 onwards, has brought in a toolkit of features designed specifically to cut through that noise. They let you say what you mean more directly, with less typing and fewer chances to make a mistake.
This is about making your code cleaner, safer, and more expressive. Let’s look at ten practical ways to do that.
Remember writing simple classes just to hold a few pieces of data? You’d need a constructor, private final fields, getter methods for each one, and then equals, hashCode, and toString. It was dozens of lines for a simple concept.
// The old way: a lot of code for a simple idea.
public final class Customer {
private final String name;
private final String email;
private final int id;
public Customer(String name, String email, int id) {
this.name = name;
this.email = email;
this.id = id;
}
public String getName() { return name; }
public String getEmail() { return email; }
public int getId() { return id; }
// ... imagine pages of equals(), hashCode(), and toString() here.
}
Now, look at this. It does the same thing.
// The modern way: the idea is the code.
public record Customer(String name, String email, int id) { }
That single line creates a final class with private final fields, a canonical constructor, getters (called name(), email()), and fully implemented equals, hashCode, and toString. It’s a transparent carrier for your data. I use records for data transfer objects, return types from methods, or as keys in a map. They make your intent crystal clear: this is data, plain and simple.
One of the most common sources of complexity is checking for null. You end up with a series of nested if statements, and it’s easy to miss a check somewhere.
// A familiar pyramid of doubt.
public String getCityOfUserManager(User user) {
if (user != null) {
Profile profile = user.getProfile();
if (profile != null) {
Address workAddress = profile.getWorkAddress();
if (workAddress != null) {
return workAddress.getCity();
}
}
}
return "City not specified";
}
This code is defensive, but it’s also procedural and hard to follow. The Optional class lets us handle this possibility explicitly. Think of an Optional as a box that might hold a value, or might be empty.
// A clear pipeline of steps that may or may not produce a value.
public String getCityOfUserManager(User user) {
return Optional.ofNullable(user)
.map(User::getProfile)
.map(Profile::getWorkAddress)
.map(Address::getCity)
.orElse("City not specified");
}
We start with the user, which might be null. Each .map() call says, “if we have a value, apply this function to it. If not, just pass the empty box along.” Finally, .orElse() provides a default if the box is empty. The logic flows from left to right, and the fallback is in one obvious place.
Old switch statements were a bit loose. You had to remember break, and they didn’t produce a result, so you had to assign a variable inside each case.
// Verbose and error-prone. Forgetting 'break' causes a fall-through.
String userRoleLabel;
switch (roleCode) {
case 1:
userRoleLabel = "Administrator";
break;
case 2:
userRoleLabel = "Editor";
break;
case 3:
userRoleLabel = "Viewer";
break;
default:
userRoleLabel = "Guest";
}
Switch expressions changed the game. They use a clean arrow -> syntax, don’t fall through, and most importantly, they produce a value.
// Compact, safe, and it yields a result directly.
String userRoleLabel = switch (roleCode) {
case 1 -> "Administrator";
case 2 -> "Editor";
case 3 -> "Viewer";
default -> "Guest";
};
You assign the result of the entire switch directly. If you’re switching on an enum, the compiler can even warn you if you’ve missed a possible case, which is a huge help for correctness.
How many times have you written an instanceof check followed by an explicit cast? It’s a ritual.
// The classic check-and-cast pattern.
if (object instanceof Payment) {
Payment p = (Payment) object;
processPayment(p.getAmount());
}
Pattern matching for instanceof combines these two steps. You test the type and declare a new variable of that type in one go.
// Cleaner and less repetitive.
if (object instanceof Payment p) {
processPayment(p.getAmount()); // 'p' is ready to use here.
}
The variable p is only in scope where we know it’s a Payment. This gets even more powerful in newer Java versions with switch pattern matching, letting you elegantly handle different types in a single control structure.
Sometimes, a set of possible types in your program is fixed. Think of the different kinds of shapes in a drawing app: Circle, Rectangle, Triangle. With a regular interface, any other class could implement Shape, which might not be what you want.
// An open hierarchy. Anyone can add a new 'Shape'.
public interface Shape { }
public class Circle implements Shape { }
public class Rectangle implements Shape { }
// Surprise! Someone else's code can add:
public class Hexagon implements Shape { }
Sealed classes and interfaces let you declare exactly which classes are allowed. You close the hierarchy.
// A controlled hierarchy. The compiler knows all the possibilities.
public sealed interface Shape permits Circle, Rectangle, Triangle { }
public final class Circle implements Shape { }
public final class Rectangle implements Shape { }
public final class Triangle implements Shape { }
// No other class outside this file can implement Shape.
This is powerful. Now, if you write a switch on a Shape, the compiler knows all the possible types. You can write an exhaustive switch without a messy default clause. It’s perfect for modeling things like commands in a system, nodes in a syntax tree, or specific states in a state machine.
We often create utility classes full of static methods for common operations. There’s nothing wrong with that, but sometimes the logic is so tightly coupled to an interface that it makes sense to live there.
// A helper sitting off to the side.
public class LoggingUtils {
public static String formatMessage(String prefix, String message) {
return "[" + prefix + "] " + message;
}
}
// Used as: LoggingUtils.formatMessage("API", "Call started");
If you have an interface where this formatting is a common need, you can use a default method.
public interface Logger {
void log(String message);
// A default implementation inside the interface.
default void logWithPrefix(String prefix, String message) {
log("[" + prefix + "] " + message);
}
}
Now, any class implementing Logger automatically gets the logWithPrefix method. It’s a great way to provide shared, reusable behavior without forcing a specific abstract class on your implementers.
Java has always demanded explicit type declarations. But sometimes, the type is screamingly obvious from the right side of the assignment.
// The type is repeated, creating visual noise.
InputStream inputStream = new FileInputStream("data.txt");
Map<String, List<Department>> departmentMap = new HashMap<String, List<Department>>();
The var keyword lets the compiler infer the type. Your focus shifts to the variable name, which is often more important.
// The intent is clear from the variable name and initializer.
var inputStream = new FileInputStream("data.txt");
var departmentMap = new HashMap<String, List<Department>>();
I find var most useful with constructors that have long class names, or with complex generic types. A good rule I follow is: use var when the type is obvious from the initializer. Don’t use it when the initializer is just null or a method with an unclear return type—clarity always wins.
Creating small, ad-hoc lists, sets, or maps used to be verbose. You’d create a mutable collection, add items, and then often wrap it to make it unmodifiable.
// Multiple steps to create a simple, fixed list.
List<String> colors = new ArrayList<>();
colors.add("Red");
colors.add("Green");
colors.add("Blue");
colors = Collections.unmodifiableList(colors);
Java introduced simple factory methods for this. They create compact, immutable collections in one line.
// One-line, immutable collections.
List<String> colors = List.of("Red", "Green", "Blue");
Set<Integer> primeCodes = Set.of(101, 103, 107);
Map<String, Integer> scores = Map.of("Alice", 95, "Bob", 87);
These are perfect for constants, for returning a fixed set of values from a method, or for passing configuration data. They’re inherently safe because they can’t be changed after creation.
A for loop that filters a list, transforms each element, and collects the results is a very mechanical process. You have to manage the loop variable, the condition, the new list, and the addition step.
// The imperative way: you specify every step.
List<String> longProductNames = new ArrayList<>();
for (Product product : productCatalog) {
if (product.getName().length() > 20) {
longProductNames.add(product.getName().toLowerCase());
}
}
The Streams API lets you describe what you want to do in a more declarative way. You focus on the operations: filter, map, collect.
// The declarative way: you describe the result.
List<String> longProductNames = productCatalog.stream()
.filter(product -> product.getName().length() > 20)
.map(product -> product.getName().toLowerCase())
.collect(Collectors.toList());
You create a stream from the source, define a chain of operations, and then terminate it with a collector. It reads more like a specification: “take the catalog, keep long names, lowercase them, and put them in a list.” An added benefit is that turning this into a parallel operation for larger datasets can be as simple as using .parallelStream().
Finally, one of the most important refactorings for robustness. Managing resources like file readers or database connections manually is risky. You have to remember to close them in a finally block, and that block itself needs its own try-catch.
// Manual cleanup is tedious and easy to get wrong.
FileWriter writer = null;
try {
writer = new FileWriter("report.txt");
writer.write(data);
} catch (IOException e) {
// handle error
} finally {
if (writer != null) {
try {
writer.close();
} catch (IOException e) {
// ignore or log
}
}
}
The try-with-resources statement automates this. You declare your resources in the try clause itself.
// Clean, safe, and automatic cleanup.
try (FileWriter writer = new FileWriter("report.txt")) {
writer.write(data);
} catch (IOException e) {
// handle error
}
Anything declared in those parentheses must implement AutoCloseable. The Java runtime guarantees that close() will be called on them when the block ends, whether it ends normally or because of an exception. It completely eliminates a whole category of resource leak bugs and makes the code much neater.
Refactoring isn’t about rewriting everything from scratch. It’s about making steady, incremental improvements. You take a small piece of code, apply one of these techniques, and leave it in a better state than you found it.
Each change makes the code a little easier to read, a little harder to break, and a little more aligned with how modern Java is written. Over time, these small changes add up, transforming a clunky, old codebase into something that’s a pleasure to work with. Start with one technique, maybe replacing a verbose constructor with a record, or simplifying a null check with Optional. You’ll quickly see the difference it makes.
