Generics can be declared on types (classes and interfaces), methods, and constructors. Wait, constructors? That one threw me a little. I’ve never actually seen or used this feature. It makes logical sense to be able to declare a generic type on a constructor; after all, it’s just a special case of a method.
I could explain how to declare and use generic constructors in a rigorous and academic way, but that doesn’t give us a sense of if or whether it’s actually a useful feature. Instead, let’s see how and how often they’re used in the real world. That’s why we have open source! Let’s look for examples of generic constructors in some of the most popular Java projects and see if we can find any patterns.
The Ceylon language takes a different approach to reading and writing files than Java. Consider the following methods in Java:
I believe that, if done right, checked exceptions can benefit an API. However, they weren’t given the proper TLC in the new Java 8 APIs, particularly in the Streams. But if Java was enhanced with default generics, the mess could be cleaned up.
When we write libraries or frameworks, we sometimes have a class
Foo whose constructor takes a
Bars, where the
Bars will be supplied by dependents.
There are many articles that explain the broad applications of Java 8’s new
Optional class (e.g., Tired of Null Pointer Exceptions? Consider Using Java SE 8’s
Optional!), but they focus on how authors can use
Optional to improve the design of their own APIs. I want to talk about how
Optional can be used to protect us from the APIs we didn’t write.
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: