Dependency management is a hard problem, and Java doesn’t make our lives any easier. Popular build tools like Maven and Gradle do what they can, but their default behavior doesn’t always alert us to potential problems. While both tools can fail when there are dependency conflicts, they’re not enabled by default. Below we will walk through the evolution of a set of modules; how they can go from having no version conflicts, to having runtime failures that should be build time failures. We’ll examine why this happens, and what tools Maven and Gradle have to help guard against it.
While not high on the list of “Things Java Could Do Better,” there’s plenty of ways we could reimagine the humble
import. For most of us, the IDE handles our imports (thank you very much), so we don’t spend a whole lot of time thinking about them. Imports are a rather arcane way to make the compiler gods happy. I think they could look a little nicer, don’t you? Let’s look at your average set of import statements (taken from the Spring Framework, PortletWrappingController.java):
As API authors, one thing we have to think about is, what happens when a method cannot fulfill its contract? Should it return
null or throw and exception? Sometimes we write both the API and its consumer. Our job—especially if your API will be used by developers that aren’t us—is to make that API as easy to use and understand as possible. While you might have heard the phrase, “use exceptions only for exceptional conditions”1, if done correctly, throwing and catching exceptions can ensure a level of correctness in our programs.
Writing Javadocs can be tedious. To make it easier, I use IntelliJ’s Live Templates. These are the Live Templates I use the most:
Consider the following “gotcha” code: