The @author
Javadoc tag is unnecessary and can even be harmful.
Java
Java’s New Versioning Scheme
Mark Reinhold announced on his blog today that Java would be updating its versioning scheme yet again. The next version of Java will be known as Java X (pronounced as in the Greek letter, chi).
What’s motivating the change? Reinhold went on to say,
Generic Constructors: What are They Good For?
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.
File I/O in Ceylon
The Ceylon language takes a different approach to reading and writing files than Java. Consider the following methods in Java:
Better Checked Exception Handing… If Java Had Default Generics
How to Spoof Empty Collection injection in Spring
When we write libraries or frameworks, we sometimes have a class Foo
whose constructor takes a Collection
of Bar
s, where the Bar
s will be supplied by dependents.
Use Optional to Shield Yourself from Bad API Design
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.
Java’s Dependency (Mis)Management: How Maven and Gradle Cope
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.
Crazy Ideas on import
Statements
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):
Should methods return null or throw an exception?
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.