A common refrain of Developers is just how verbose the language is, especially compared to its more dynamic counterparts like Scala or Ruby. While Java cannot be made as concise as a true dynamic language, it is still possible to make the code more readable and provide clarity to the business logic.
What Makes a Language More Concise
Verbose code is possible in any language. The language's structure, standard library and the common idioms are the limiting factors in how concise a developer can make the code. Brevity is as important as clarity.
These are some tricks that I've learned to help make Java less Java-like.
Explicit vs Convention
In my opinion, this is the easiest way to make code that is both clean and understandable. Frameworks like Ruby on Rails reduce the configuration that maps components together, opting instead to define the relationships through standard conventions. Models go in one place and extend a common class, the same with controllers. There is meta programming and magic everywhere, but the consistency of how it's applied keep the system maintainable.
Aspect Oriented Programming is Java's mechanism for dealing with cross-cutting concerns. Logging, transactions, and security are all examples of these types of concerns.
The following is relatively common Java code (all code in this post is for illustration, it probably doesn't run):
The business logic is very simple, but there is a lot of boilerplate. By using AOP, the method could be reduced to:
With all the boilerplate removed, it is much easier to understand what the business logic of this segment of code is. AOP allows us to accomplish this by adding
joinpoints, which in this case is the method
saveBlogPost. I won't go into details of how to implement AOP here and instead point you to a primer.
Annotations not XML
Annotations can be coupled with AOP to make code much simpler. Spring MVC has a great library of annotations that make creating a web app much simpler.
Annotations can also replace XML for more general configuration. An example of this is Hibernate. From the Hibernate doc, the traditional, way to map a class would be the following:
Annotations simplify this by allowing the developer to write:
By declaring the mapping properties with the properties themselves, the developer can cut down on an additional file containing essentially the same information as the POJO.
Sometimes you want to call common functionality in a situation where an
abstract or parent class does not make much sense.
Mix-ins are a popular approach for code libraries for common code that does not match an inheritance library. The JAVA version is are the more cumbersome
static common classes. Not one can one not share state but the syntax requires explicit call outs to other classes.
At least the latter can be fixed with static imports. Therefore, it is possible to turn:
I find this relatively minor piece of syntactic sugar helps a lot with code clarity, especially if care is taking to name the methods correctly.
Anytime one makes a style decision that take the approach way from the most idiomatic form, there is a potential to create something that is difficult to maintain. The desire to make code more readable by removing boilerplate definitely comes with trade-offs. If other developers are not familiar with the patters or, as is the case with AOP, the patterns themselves are difficult to debug, the cost to support the software may increase.
However, I find that making code simpler also makes it easier to develop and more approachable for the most common cases of maintenance. These are not the only approaches and the newer versions of Java will have even more support for advanced language concepts (closure support for one). Despite the reputation, simplicity is possible and writing Java can feel as lightweight as using more trendy, dynamic languages.
Did you like this? Please share:
The Lost Year: A Failed Experiment to Switch Away From Mac
Fed up with the Apple Keyboard, I bought a ThinkPad, installed Linux, and promptly decided that I hated computers.
Maker's Space, Manager's Space
The Grand Remote Work Experiment: A Retrospective
The COVID-19 pandemic has lead to an unexpected experiment in remote working. What has worked and why?