1. All You Need Is Java – 97 Things Every Java Programmer Should Know

Chapter 1. All You Need Is Java

Anders Norås

While working on the first major revision of Visual Studio, the team at Microsoft introduced the world to three developer personas: Mort, Elvis, and Einstein. 

Mort was the opportunistic developer, doing quick fixes and making things up as he went along. Elvis was the pragmatic programmer, building solutions for the ages while learning on the job. Einstein was the paranoid programmer, obsessed with designing the most efficient solution and figuring everything out before writing his code.

On the Java side of the religious divide of programming languages, we laughed at Morts, and we wanted to be Einsteins building frameworks to make sure the Elvises wrote their code the “right way.”

This was the dawn of the age of the frameworks, and unless you were proficient with the latest, greatest object relational mapper and inversion of control framework, you weren’t a proper Java programmer. Libraries grew into frameworks with prescripted architectures. And as these frameworks became technology ecosystems, many of us forgot about the little language that could—Java.

Java is a great language and its class library has something for every occasion. Need to work with files? java.nio’s got you covered. Databases? java.sql is the place to go. Almost every Java distribution even sports a full-blown HTTP server, even if you have to climb off the Java-named branch and onto com.sun.net.httpserver.

As our applications move toward serverless architectures, where the deployment units can be single functions, the benefits we get from application frameworks diminish. This is because we’ll likely spend less time on handling technical and infrastructural concerns, focusing our programming efforts toward the business capabilities our programs realize.

As Bruce Joyce put it:

We have to reinvent the wheel every once in a while, not because we need a lot of wheels; but because we need a lot of inventors.

Many have set out to build generic business logic frameworks to maximize reuse. Most have failed since there really aren’t any generic business problems. Doing something special in a specific way is what sets one business apart from the next. This is why you’re guaranteed to be writing business logic on just about every project. In the name of coming up with something generic and reusable, one might be tempted to introduce a rules engine or similar. At the end of the day, configuring a rules engine is programming, often in a language inferior to Java. Why not try to just write Java instead? You’ll be surprised to find that the end result will be easy to read, which in turn makes the code easy to maintain—even by non-Java programmers.

Quite often you’ll find that Java’s class library is a little limited, and you might need something to make working with dates, networking, or something else a little more comfortable. That’s fine. Use a library. The difference is that you’ll now be using that library because a specific need occurred, not because it was part of the stack you’ve always been using.

The next time an idea for a small program springs to mind, awaken your knowledge of the Java class library from hibernation rather than reaching for that JHipster scaffold. Hipsterism is passé; living a simple life is where it’s at now. I bet Mort loved the simple life.