5 Habits Java Experts Like to See

Seasoned Java developers like to see these practices in the PR

Photo by Tima Miroshnichenko from Pexels — Edits by author

Most Java experts like to see these practices from younger developers.

After seeing a lot of PRs myself, I do like to see the next habits. You’ll agree, others also like these practices. Most of these increase Java code readability, and performance, and some reduce verbosity.

Let’s see what practices experts like to see from younger developers.

1. You use method references when possible

Even so, most developers create big lambdas.

Small-sized lambdas are easier to read and have better performance. When possible put as few lines into lambdas as possible. Even better use method references and if possible unbound ones.

Do you see a similar lambda code? Extract these, and use a method reference.

It’s better to use the unbound method reference, Class::yourMethod. As there’s a small performance hit with bound ones, Instance::yourMethod. Also, the readability of method references is better than with duplicated lambda code.

2. You translate exceptions

Read more on exception translation.

Here’s what James Gosling says about exception translation:
That’s a place where exception translation can be a good thing. Let’s say you have software reading a database. Somewhere deep inside it, it could get a MalformedURLException. It doesn’t make sense to propagate that outward as a MalformedURLException.

It’s better to think about what kind of exceptions are a part of the interface. And not an artifact of how the underlying method was implemented. In the Java exceptions mechanism, you can wrap cause inside an exception. So you create a new IOException, and you set its cause to this MalformedURLException. And you bundle them together. That’s been very effective.

No one likes to see this piece of code:

throw ex;

You’d lose stack trace with this approach. Even only throw isn’t a good way to go.

A better way would be to rethrow your custom exception. If you don’t know how to handle it on a lower level, translate to a higher-level exception.

throw new CustomException(ex);

3. You use enums for constants

You can see constants-only interfaces in some codebases. Even so, they’re an anti-pattern.

Enums are the better choice for constants.

You can add custom methods to the enum. Or iterate over values, or cache them to improve performance. And use them in appropriate enum structures.

Another thing I like about enums is cohesion. They wrap similar constants together. While in interfaces it can get messy. Here’s an example:

4. You avoid exception anti-patterns

The ones I dislike the most are exception swallowing and an empty catch.

There are others such as:

• log-rethrow
• exposing security details
• translation of checked into unchecked exceptions.

You should handle the exception or translate the exception. You don’t do both.

Also, you don’t translate to runtime exceptions. You first need to understand the difference between checked and unchecked exceptions.

“Use checked exceptions for recoverable conditions and runtime exceptions for programming errors.” — Joshua Bloch

5. You use varargs when needed

Even though cleaner in some scenarios these may pose an issue.

For example when varargs are mixed with generics. Varargs creates an array that suffers from unchecked casts. So it’s your job to ensure type safety.

// Joshua Bloch - Item 32 - snippet around type safety
**// Mixing generics and varargs can violate type safety!**
static void dangerous(**List<String>... stringLists**) {
    List<Integer> intList = List.of(42);
    Object[] objects = stringLists;
    objects[0] = intList;             **// Heap pollution**
    String s = stringLists[0].get(0); **// ClassCastException**
}

When you need variable arity, or to pass in an array of arguments, you should use varargs. Even though it creates an Object[] it’s more concise, and readable. Hopefully, in the future, the array would be converted to an immutable list.

Takeaway

Enums are defacto tools for creating constants.

That’s like that for a good reason. They’re readable, performant, and concise. As such there’s no need for younger developers to ignore them.

Also, younger developers don’t invest time in exceptions.

I don’t like creating exception towns, but even some basic knowledge is lacking. Junior knowing the difference between checked and unchecked exceptions, as I’ve mentioned, is something experts like to see.