Design and build a collaborative user experience for a chance to win cool prizes!
Blog

Top 5 Productivity Libraries for Java developers

By  
Matti Tahvonen
Matti Tahvonen
·
On Jun 2, 2022 3:35:38 PM
·

Java productivity libraries

Productivity in developing UIs is the heart and soul of Vaadin. But UI is just a portion of your application. There are a huge number of libraries available for Java developers that help you to be more productive than with pure JDK. For this article, we collected our favorite libraries that share the same goal as Vaadin: helping you to create quality software – faster.

These are libraries that you can drop into almost any project without a gazillion of other transitive dependencies. We have left out libraries that we consider to be more like framework features, such as dependency injection frameworks or, for example, Spring Data.

Project Lombok

Due to the rather verbose conventions in Java, we have all become masters in writing getters, setters, constructors, and so on. IDE features to generate these methods are in the toolbox of most Java developers, but maintaining those methods, especially in the early phases of development, can be a burden.

Project Lombok can be your secretary for many of these tasks that need mechanical coding. For example, based on annotation processing, it can maintain your getters, setters, constructors, toString methods, and so on. Your data classes will look a lot simpler in the editor and refactoring looks very clear in the GIT history.

@Entity
@Getter @Setter @NoArgsConstructor
public class Competition extends AbstractEntity {
   private String name;
   private LocalDateTime start;
   private LocalDateTime end;
   private boolean open;
   private Integer startIntervalSeconds = 60;
   @OneToMany(mappedBy="competition", cascade = CascadeType.ALL)
   private List<SeriesGroup> seriesGroups;
}

A JPA entity whose required getters, setters and no-argument constructor are implemented automatically using Lombok. The @Getter, @Setter and @NoArgsConstructor are from Lombok.

Lombok can give you a great productivity boost, especially at the beginning of the project, but it can also be a great source of issues if you are “holding it wrong” or don’t understand what it is doing. For example, the equals and hashCode implementations it can write for you make your data objects incompatible with standard JDK collection classes such as lists, sets, and maps. I have also heard nasty stories about IDE setup in large projects. IntelliJ users are lucky when using Lombok, because the tooling comes built-in with the latest versions.

When I was discussing this article with one of my colleagues, he sarcastically suggested listing Delombok as one of the top productivity libraries. He sure had some nasty issues using Lombok in his project, but there is some wisdom in his comment. Lombok has a feature called Delombok that removes all Lombok annotations from your code and replaces them with the generated code. When your project gets to a more stable phase, it might make sense to simplify the project setup. It is also impossible to add JavaDocs to methods that are maintained by Lombok.

Lombok can be added to your project with following Maven dependency:

<dependency>
   <groupId>org.projectlombok</groupId>
   <artifactId>lombok</artifactId>
   <version>1.18.24</version>
   <scope>provided</scope>
</dependency>

Apache Commons libraries

The Apache Foundation has a long history of complementing JDK’s built-in general purpose libraries with various commons libraries. There are a lot of handy shorthands and helper methods available – for example, String and input and output stream handling. Some of these have become less relevant in recent years as JDK itself has developed, but they still provide great enhancements to Java’s core libraries.

The most notable libraries a productive Java developer should know about are commons-lang3 and commons-collections. A full list of all the commons libraries can be found at commons.apache.org.

Similar in nature to the various Apache Commons libraries is Guava. Instead of being split into multiple libraries, it has a larger productivity library with a single dependency. Guava is largely built by Google’s Java developers and there is also a version of the library that works in Android development.

Maven snippet for Commons Lang:

<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-lang3</artifactId>
    <version>3.12.0</version>
</dependency>

Maven snippet for Commons Collections:

<dependency>
    <groupId>org.apache.commons</groupId>
    <artifactId>commons-collections4</artifactId>
    <version>4.4</version>
</dependency>

Jsoup

HTML has become the de facto standard as a rich text format. Even if your application isn’t actually a web app or your web framework is Vaadin, which allows you to write web apps without a single line of HTML, there is a high chance that at some point you will need to get involved in HTML markup. Jsoup parses the HTML and allows programmatic manipulation.

A good reason for mastering Jsoup is security. The fact that it actually parses the document object model makes it a very safe way to sanitize HTML input coming from untrusted sources.

getElement().setProperty("innerHTML",
  Jsoup.clean(
    "<b onclick=\"alert('see no evil')\">All good!</b>",
    Safelist.basic())
);

Using Jsoup to clean “evil Javascript” from HTML to set a Vaadin component.

We use Jsoup at Vaadin in our Flow framework, so Vaadin developers get it in their project anyways as a transitive dependency. 

Maven snippet for Jsoup:

<dependency>
    <groupId>org.jsoup</groupId>
    <artifactId>jsoup</artifactId>
    <version>1.15.1</version>
</dependency>

Mockito

Mocking is a unit testing technique that allows you to verify the behavior of smaller units of your application, instead of making them actually integration tests. Mocks replace other components during the test and still allow you to verify the correct behavior.

The Mockito library helps you to write mocks much faster than doing it manually. Mockito has become almost a standard library for many professional Java developers.

Maven dependency for Mockito:

<dependency>
  <groupId>org.mockito</groupId>
  <artifactId>mockito-core</artifactId>
  <version>4.5.1</version>
</dependency>

Ehcache

There are only two hard things in Computer Science: cache invalidation and naming things.

Famous quote by Phil Karlton. We probably won’t ever be able to solve the naming problem completely, but with cache invalidation, an advanced library might help. Ehcache is one of the most popular ones in the JVM ecosystem. It is handy for quick in-memory caching, but can be configured to push rarely accessed items to the disk if your cache needs to be large.

In simple cases, you can probably use Ehcache as an implementation of the standard JCache API, to keep a direct dependency on Ehcache away from your application. For more complex use cases, Ehcache can also be easily distributed to multiple JVMs in your cluster using the Terracotta server.

Maven dependency for Ehcache:

<dependency>
      <groupId>org.ehcache</groupId>
      <artifactId>ehcache</artifactId>
      <version>3.10.0</version> 
    </dependency>

Use them boldly, but not recklessly

All of the tools introduced in this article are stable pieces of software and proven in production. If you find that they help write software faster or, in other words, if you can avoid writing code for problems that have already been solved, put them to use. 

Note that all of these libraries are still actively maintained. If you used the above Maven snippets to add them to your project, be sure to use the latest release with mvn versions:use-latest-releases.

But remember that every dependency you add to your application makes it a bit more complex and more fragile. If you already have Guava in your project, there is a fair chance you don’t need commons-lang for your application. Discuss with your team which libraries you want to use and what the policies are with regard to adding new ones!

Have you tried Vaadin yet? Get started today!

Matti Tahvonen
Matti Tahvonen
Matti Tahvonen has a long history in Vaadin R&D: developing the core framework from the dark ages of pure JS client side to the GWT era and creating number of official and unofficial Vaadin add-ons. His current responsibility is to keep you up to date with latest and greatest Vaadin related technologies. You can follow him on Twitter – @MattiTahvonen
Other posts by Matti Tahvonen