Java is one of the most popular programming languages around, but no one seems
to enjoy using it. Well, Java is actually an alright programming language, and
since Java 8 came out recently, I decided to compile a list of libraries,
practices, and tools to make using Java better.
This article is on Github. Feel free to
contribute and add your own Java tips and best practices.
Style
Structs
The Builder Pattern
Dependency injection
Avoid Nulls
Immutable-by-default
Avoid lots of Util classes
Formatting
Javadoc
Streams
Deploying
Frameworks
Maven
Dependency Convergence
Continuous Integration
Maven repository
Configuration management
Libraries
Missing Features
Apache Commons
Guava
Gson
Java Tuples
Joda-Time
Lombok
Play framework
SLF4J
jOOQ
Testing
jUnit 4
jMock
AssertJ
Tools
IntelliJ IDEA
Chronon
JRebel
The Checker Framework
Eclipse Memory Analyzer
Resources
Books
Podcasts
Style
Traditionally, Java was programmed in a very verbose enterprise JavaBean style.
The new style is much cleaner, more correct, and easier on the eyes.
Structs
One of the simplest things we as programmers do is pass around data. The
traditional way to do this is to define a JavaBean:
This is verbose and wasteful. Even if your IDE automatically generated this
code, it's a waste. So, don't do this.
Instead, I prefer the C struct style of writing classes that merely hold data:
This is a reduction in number of lines of code by a half. Further, this class
is immutable unless you extend it, so we can reason about it easier as we know
that it can't be changed.
If you're storing objects like Map or List that can be modified easily, you
should instead use ImmutableMap or ImmutableList, which is discussed in the
section about immutability.
The Builder Pattern
If you have a rather complicated object that you want to build a struct for,
consider the Builder pattern.
You make a subclass in your object which will construct your object. It uses
mutable state, but as soon as you call build, it will emit an immutable
object.
Imagine we had a more complicated DataHolder. The builder for it might look
like:
Then to use it:
There are better examples of Builders elsewhere but this should
give you a taste for what it's like. This ends up with a lot of the boilerplate
we were trying to avoid, but it gets you immutable objects and a very fluent
interface.
Dependency injection
This is more of a software engineering section than a Java section, but one of
the best ways to write testable software is to use dependency injection
(DI). Because Java strongly encourages OO design, to make testable software,
you need to use DI.
In Java, this is typically done with the Spring Framework. It has a
either code-based wiring or XML configuration-based wiring. If you use the XML
configuration, it's important that you don't overuse Spring because
of its XML-based configuration format. There should be absolutely no logic or
control structures in XML. It should only inject dependencies.
Good alternatives to using Spring is Google and Square's Dagger
library or Google's Guice. They don't use Spring's XML
configuration file format, and instead they put the injection logic in
annotations and in code.
Avoid Nulls
Try to avoid using nulls when you can. Do not return null collections when you
should have instead returned an empty collection. If you're going to use null,
consider the @Nullable annotation. IntelliJ IDEA has
built-in support for the @Nullable annotation.
If you're using Java 8, you can use the excellent new
Optional type. If a value may or may not be present, wrap it in
an Optional class like this:
So now it's clear that data will never be null, but bar may or may not be
present. Optional has methods like isPresent, which may make it feel like
not a lot is different from just checking null. But it allows you to write
statements like:
Which is much better than chained if null checks. The only downside of using
Optional is that the standard library doesn't have good Optional support, so
dealing with nulls is still required there.
Immutable-by-default
Unless you have a good reason to make them otherwise, variables, classes, and
collections should be immutable.
Variable references can be made immutable with final:
Now you can be sure that fooWidget won't be accidentally reassigned. The final
keyword works with if/else blocks and with try/catch blocks. Of course, if the
fooWidget itself isn't immutable you could easily mutate it.
Collections should, whenever possible, use the Guava ImmutableMap,
ImmutableList, or ImmutableSet classes. These
have builders so that you can build them up dynamically and then mark them
immutable by calling the build method.
Classes should be made immutable by declaring fields immutable (via final)
and by using immutable collections. Optionally, you can make the class itself
final so that it can't be extended and made mutable.
Avoid lots of Util classes
Be careful if you find yourself adding a lot of methods to a Util class.
These classes, at first, seem attractive because the methods that go in them
don't really belong in any one place. So you throw them all in here in the
name of code reuse.
The cure is worse than the disease. Put these classes where they belong, or
if you must have common methods like this, consider Java 8's default
methods on interfaces. Then you could lump common actions into interfaces.
And, since they're interfaces, you can implement multiple of them.
Then every class which needs it can simply implement this interface.
Formatting
Formatting is so much less important than most programmers make it out to be.
Does consistency show that you care about your craft and does it help others
read? Absolutely. But let's not waste a day adding spaces to if blocks so that
it "matches".
If you absolutely need a code formatting guide, I highly recommend
Google's Java Style guide. The best part of that guide is the
Programming Practices section. Definitely worth a read.
Javadoc
Documenting your user facing code is important. And this means
using examples and using sensible descriptions of variables,
methods, and classes.
The corollary of this is to not document what doesn't need documenting. If you
don't have anything to say about what an argument is, or if it's obvious,
don't document it. Boilerplate documentation is worse than no documentation at
all, as it tricks your users into thinking that there is documentation.
Streams
Java 8 has a nice stream and lambda syntax. You could
write code like this:
Instead of this:
This allows you to write more fluent code, which is more readable.
Deploying
Deploying Java properly can be a bit tricky. There are two main ways to deploy
Java nowadays: use a framework or use a home grown solution that is more
flexible.
Frameworks
Because deploying Java isn't easy, frameworks have been made which can help.
Two of the best are Dropwizard and Spring Boot.
The Play framework can also be considered one of these deployment
frameworks as well.
All of them try to lower the barrier to getting your code out the door.
They're especially helpful if you're new to Java or if you need to get things
done fast. Single JAR deployments are just easier than complicated WAR or EAR
deployments.
However, they can be somewhat inflexible and are rather opinionated, so if
your project doesn't fit with the choices the developers of your framework
made, you'll have to migrate to a more hand-rolled configuration.
Maven
Good alternative: Gradle.
Maven is still the standard tool to build, package, and run your tests. There
are alternatives, like Gradle, but they don't have the same adoption that Maven
has. If you're new to Maven, you should start with
Maven by Example.
I like to have a root POM with all of the external dependencies you want to
use. It will look something like this. This root POM has only one
external dependency, but if your product is big enough, you'll have dozens.
Your root POM should be a project on its own: in version control and released
like any other Java project.
If you think that tagging your root POM for every external dependency change
is too much, you haven't wasted a week tracking down cross project dependency
errors.
All of your Maven projects will include your root POM and all of its version
information. This way, you get your company's selected version of each
external dependency, and all of the correct Maven plugins. If you need to pull
in external dependencies, it works just like this:
If you want internal dependencies, that should be managed by each individual
project's
section. Otherwise it would be difficult
to keep the root POM version number sane.
Dependency Convergence
One of the best parts about Java is the massive amount of third party
libraries which do everything. Essentially every API or toolkit has a Java SDK
and it's easy to pull it in with Maven.
And those Java libraries themselves depend on specific versions of other
libraries. If you pull in enough libraries, you'll get version conflicts, that
is, something like this:
Which version will get pulled into your project?
With the Maven dependency convergence plugin, the build will
error if your dependencies don't use the same version. Then, you have two
options for solving the conflict:
Explicitly pick a version for Bar in your dependencyManagement section
Exclude Bar from either Foo or Widget
The choice of which to choose depends on your situation: if you want to track
one project's version, then exclude makes sense. On the other hand, if you
want to be explicit about it, you can pick a version, although you'll need to
update it when you update the other dependencies.
Continuous Integration
Obviously you need some kind of continuous integration server which is going
to continuously build your SNAPSHOT versions and tag builds based on git tags.
Jenkins and Travis-CI are natural choices.
Code coverage is useful, and Cobertura has
a good Maven plugin and CI support. There are other code
coverage tools for Java, but I've used Cobertura.
Maven repository
You need a place to put your JARs, WARs, and EARs that you make, so you'll
need a repository.
Common choices are Artifactory and Nexus. Both work,
and have their own pros and cons.
You should have your own Artifactory/Nexus installation and
mirror your dependencies onto it. This will stop your
build from breaking because some upstream Maven repository went down.
Configuration management
So now you've got your code compiled, your repository set up, and you need to
get your code out in your development environment and eventually push it to
production. Don't skimp here, because automating this will pay dividends for a
long time.
Chef, Puppet, and Ansible are typical choices.
I've written an alternative called Squadron, which I, of course,
think you should check out because it's easier to get right than the
alternatives.
Regardless of what tool you choose, don't forget to automate your deployments.
Libraries
Probably the best feature about Java is the extensive amount of libraries it
has. This is a small collection of libraries that are likely to be applicable
to the largest group of people.
Missing Features
Java's standard library, once an amazing step forward, now looks like it's
missing several key features.
Apache Commons
The Apache Commons project has a bunch of useful libraries.
Commons Codec has many useful encoding/decoding methods for Base64 and hex
strings. Don't waste your time rewriting those.
Commons Lang is the go-to library for String manipulation and creation,
character sets, and a bunch of miscellaneous utility methods.
Commons IO has all the File related methods you could ever want. It has
FileUtils.copyDirectory, FileUtils.writeStringToFile,
IOUtils.readLines and much more.
Guava
Guava is Google's excellent here's-what-Java-is-missing library. It's
almost hard to distill everything that I like about this library, but I'm
going to try.
Cache is a simple way to get an in-memory cache that can be used to cache
network access, disk access, memoize functions, or anything really. Just
implement a CacheBuilder which tells Guava how to build your
cache and you're all set!
Immutable collections. There's a bunch of these: ImmutableMap,
ImmutableList, or even ImmutableSortedMultiSet
if that's your style.
I also like writing mutable collections the Guava way:
There are static classes for Lists, Maps, Sets and
more. They're cleaner and easier to read.
If you're stuck with Java 6 or 7, you can use the Collections2
class, which has methods like filter and transform. They allow you to write
fluent code without Java 8's stream support.
Guava has simple things too, like a Joiner that joins strings on
separators and a class to handle interrupts by ignoring them.
Gson
Google's Gson library is a simple and fast JSON parsing library. It
works like this:
It's really easy and a pleasure to work with. The Gson user guide
has many more examples.
Java Tuples
One of my on going annoyances with Java is that it doesn't have tuples built
into the standard library. Luckily, the Java tuples project fixes
that.
It's simple to use and works great:
Joda-Time
Joda-Time is easily the best time library I've ever used. Simple,
straightforward, easy to test. What else can you ask for?
You only need this if you're not yet on Java 8, as that has its own new
date time library that doesn't suck.
Lombok
Lombok is an interesting library. Through annotations, it allows you
to reduce the boilerplate that Java suffers from so badly.
Want setters and getters for your class variables? Simple:
Now you can do this:
And there's so much more. I haven't used Lombok in production
yet, but I can't wait to.
Play framework
Good alternatives: Jersey or Spark
There are two main camps for doing RESTful web services in Java:
JAX-RS and everything else.
JAX-RS is the traditional way. You combine annotations with interfaces and
implementations to form the web service using something like Jersey.
What's nice about this is you can easily make clients out of just the
interface class.
The Play framework is a radically different take on web services on
the JVM: you have a routes file and then you write the classes referenced in
those routes. It's actually an entire MVC framework, but you can
easily use it for just REST web services.
It's available for both Java and Scala. It suffers slightly from being
Scala-first, but it's still good to use in Java.
If you're used to micro-frameworks like Flask in Python, Spark will
be very familiar. It works especially well with Java 8.
SLF4J
There are a lot of Java logging solutions out there. My favorite is
SLF4J because it's extremely pluggable and can combine logs from many
different logging frameworks at the same time. Have a weird project that uses
java.util.logging, JCL, and log4j? SLF4J is for you.
The two-page manual is pretty much all you'll need to get
started.
jOOQ
I dislike heavy ORM frameworks because I like SQL. So I wrote a lot of
JDBC templates and it was sort of hard to maintain. jOOQ is a
much better solution.
It lets you write SQL in Java in a type safe way:
Using this and the DAO pattern, you can make database access a breeze.
Testing
Testing is critical to your software. These packages help make it easier.
jUnit 4
jUnit needs no introduction. It's the standard tool for unit testing
in Java.
But you're probably not using jUnit to its full potential. jUnit supports
parametrized tests, rules to stop you from writing
so much boilerplate, theories to randomly test certain code,
and assumptions.
jMock
If you've done your dependency injection, this is where it pays off: mocking
out code which has side effects (like talking to a REST server) and still
asserting behavior of code that calls it.
jMock is the standard mocking tool for Java. It looks like this:
This sets up a FooWidgetDependency via jMock and then adds expectations. We
expect that dep's call method will be called once with some String and that
dep's optionalCall method will be called zero or more times.
If you have to set up the same dependency over and over, you should probably
put that in a test fixture and put assertIsSatisfied in an
@After fixture.
AssertJ
Do you ever do this with jUnit?
This is just annoying boilerplate. AssertJ solves this. You can
transform the same code into this:
This fluent interface makes your tests more readable. What more could you want?
Tools
IntelliJ IDEA
Good alternatives: Eclipse and Netbeans
The best Java IDE is IntelliJ IDEA. It has a ton of awesome
features, and is really the main thing that makes the verbosity of Java
bareable. Autocomplete is great,
the inspections are top notch, and the refactoring
tools are really helpful.
The free community edition is good enough for me, but there are loads of great
features in the Ultimate edition like database tools, Spring Framework support
and Chronon.
Chronon
One of my favorite features of GDB 7 was the ability to travel back in time
when debugging. This is possible with the Chronon IntelliJ plugin
when you get the Ultimate edition.
You get variable history, step backwards, method history and more. It's a
little strange to use the first time, but it can help debug some really
intricate bugs, Heisenbugs and the like.
JRebel
Continuous integration is often a goal of software-as-a-service products. What
if you didn't even need to wait for the build to finish to see code changes
live?
That's what JRebel does. Once you hook up your server to your JRebel
client, you can see changes on your server instantly. It's a huge time savings
when you want to experiment quickly.
The Checker Framework
Java's type system is pretty weak. It doesn't differentiate between Strings
and Strings that are actually regular expressions, nor does it do any
taint checking. However, the Checker Framework
does this and more.
It uses annotations like @Nullable to check types. You can even define
your own annotations to make the static analysis done even
more powerful.
Eclipse Memory Analyzer
Memory leaks happen, even in Java. Luckily, there are tools for that. The best
tool I've used to fix these is the Eclipse Memory Analyzer. It takes a
heap dump and lets you find the problem.
There's a few ways to get a heap dump for a JVM process, but I use
jmap:
Then you can open the heapdump.hprof file with the Memory Analyzer and see
what's going on fast.
Resources
Resources to help you become a Java master.
Books
Effective Java
Java Concurrency in Practice
Podcasts
The Java Posse