SDA Dropwizard Commons v3

This article was happily co-created by Christopher, Preethi, Jörg & ChatGPT.

It’s about time! More than 2 years after the last major version we are happy to announce that version 3 of sda-dropwizard-commons is out. Let’s see what has changed!

SDA Dropwizard Commons is a set of libraries to bootstrap services easily that follow the patterns and specifications promoted by the SDA SE. It’s built on top of Dropwizard: “Dropwizard pulls together stable, mature libraries from the Java ecosystem into a simple, light-weight package that lets you focus on getting things done.” It includes a collection of libraries and tools for tasks such as configuration, logging, and health checks, and can be used as a fast and convenient way to develop web applications.

The main goal of providing the next major version of sda-dropwizard-commons was to finally support Java 17. The changes that had the most effect on writing code and which broke many libraries was about the encapsulation of the internal JDK classes and preventing to access fields by reflection. If you’re interested in details, I can recommend this blog post. If not, I’ll summarize it like this: It caused a lot of trouble. ;)

These are the highlights of the new version:

• Java 17 support
• Spring Data Mongo for MongoDB access
• OpenTelemetry
• JUnit 5

It will drop support for:

• Morphia
• OpenTracing
• JUnit 4
• Java 8
• OpenAPI 2 (aka Swagger)

You can find all changes that will affect you in the migration guide.

Disclaimer regarding the following text: As most good technicians we’re really good at writing code but pretty bad at writing witty articles. Thus, we played around with ChatGPT to help us fill the empty spaces. We will highlight if texts were created by that engine.

Breaking changes… a science fiction story

Credits to ChatGPT for writing the following story:

In the year 2050, humanity had colonized several planets and had built a vast network of interconnected systems that controlled everything from transportation to communication. These systems relied on a complex network of libraries and algorithms to function smoothly.

One day, a new version of one of the libraries that powered the systems was released. This new version included a lot of exciting new features and important dependency updates. However, it also included some breaking changes that would require the developers to update their systems.

Despite the initial hesitance of many developers, a visionary named Ava convinced them to take the leap and update their systems to the new library version. Ava explained that the new version was more advanced and would allow the systems to function even more efficiently.

The developers were sceptical, but Ava convinced them by telling them a story from her own experience: “I was part of a team that built a system for a colony on a distant planet. We were hesitant to update our libraries, just like you are now. But we eventually decided to take the leap and update.

To our surprise, the new version allowed our systems to function at a much higher level of efficiency. We were able to perform tasks much faster and with greater accuracy. And, most importantly, the new version prevented a major system failure that would have devastated the colony.

In the same way, updating to the new version of the library, despite some breaking changes, will allow your systems to function at a much higher level of efficiency. The new features and dependency updates will provide greater stability and prevent future failures.”

The developers took Ava’s advice and updated their systems to the new library version. To their delight, the systems functioned even better than before, and they were able to take advantage of all the new features and benefits that the new version offered. They learned that updating is not always easy, but it is always a good idea in the long run.

In conclusion, updating to a new version of a library, even if it includes some breaking changes, is a good idea because it can offer many new features and benefits. Updating keeps your systems current, secure, and efficient, allowing you to take advantage of the latest advancements in technology.

What changed in detail

Java 17

Oracle changed the frequency and strategy of their JDK releases. They are now releasing more often which results in more versions. On the other side not all version are long-living but they decide on some long-term supported (LTS) versions. The next LTS version after 8 and 11 is 17 which was the target for v3 of sda-dropwizard-commons. We will still support Java 11 but drop support for Java 8. In addition it will now also support Java 17.

Since sda-dropwizard-commons brings a lot of dependencies, we had to wait for a while until all libraries had ironed out their creases. The last library that we were waiting for was the library that we used for accessing MongoDB, i.e. Morphia. You can read more about what happened to Morphia below.

In general we recommend to update to Java 17 now because older versions are getting close to run out of the official support. Do you need more arguments why you should upgrade?

Java 8 is enough, I don’t need new features

[ChatGPT, why should you upgrade from Java 8?]

1. End of public support: It has reached its end of public support, which means that it will no longer receive public updates, security patches, or bug fixes from Oracle. This can leave your applications vulnerable to security threats and make it difficult to address bugs or performance issues.
2. Lack of new language features: It does not include many of the newer language features that have been added in more recent versions of Java like the new records feature in Java 14. These features can make your code more concise and easier to read, as well as support new programming paradigms and use cases.

… but Java 11 is still good, isn’t it?

The end of support for Java 11 is coming closer. It depends on your JRE distribution. Eclipse Temurin for example provides Java 11 until 2024.

Java 17 highlights

[ChatGPT: What are the highlights of Java 17?] Java 17 is the latest Java version with long-term support and comes with various improvements over Java 11. These are:

1. Improved performance: It includes performance improvements, such as faster startup times and reduced memory usage, which can make your applications run more efficiently.
2. Enhanced security: It includes updates to the security model that make it easier to develop secure applications and protect against common threats such as malware and data breaches.
3. New language features: It introduces new language features, such as pattern matching for instanceof, that can make your code more concise and easier to read.
4. Better support for modern hardware: It includes support for modern hardware features, such as hardware-accelerated cryptography and improved support for low-latency applications.

What happened with Morphia?

Morphia was the library that gave us the greatest headaches. We had to wait for quite some time for version 2 that finally brought support for Java 17. Unfortunately it also contained a lot of breaking changes. It removed the possibility to register custom type converters, removed the validation feature, etc. After discussing the issues and waiting for the next releases we also had internal discussions. In the end we decided to drop using Morphia because it can just not keep up with the feature richness, quality of documentation and community of Spring Data Mongo. We did not take this step lightly and know about the impact on your code. Nevertheless we felt it was the best decision in the long term.

OpenTracing → OpenTelemetry

OpenTracing was archived some time ago. Time to migrate to its successor OpenTelemetry.

[ChatGPT, why should we migrate from OpenTracing to OpenTelemetry?] Migrating is a smart move for organizations seeking to modernize their observability stacks and stay ahead of the curve in terms of performance and functionality. Why migrate??

1. Standardization: OpenTelemetry was created as a result of the merge between OpenTracing and OpenCensus. This collaboration has resulted in a single, unified standard for telemetry data collection and analysis. With OpenTelemetry, you have a consistent, vendor-neutral approach to telemetry that is easy to understand and use.
2. Improved Performance: OpenTelemetry provides a much more efficient way to collect and transmit telemetry data. It uses a lighter-weight data format, which results in lower overhead and improved performance. This means that you can collect and analyze data faster, and at scale.
3. Wider Ecosystem: OpenTelemetry has a much larger and more active community of contributors, which means that you have access to a wider range of tools and services for monitoring, analyzing, and visualizing your telemetry data. This makes it easier for you to find the right tools for your needs and get started quickly.
4. Future-Proof: With its strong focus on standardization and its broad community of contributors, OpenTelemetry is the future of telemetry data collection. By migrating to OpenTelemetry, you can ensure that your organization is prepared for the future of observability and telemetry.

Kafka Bundle

Bundles are Dropwizard’s way to provide functionality for specific use cases. The Kafka bundle provides ways to create consumers and producers. In version 3 we cleaned up the bundle and removed some functionalities that we think should not be part of it. We removed code that enabled services to create topics and to enforce specific topic configurations. In our opinion that is not the responsibility of the developer of a service to decide. Furthermore, in a microservice environment, it is common for a dedicated team to be responsible for managing the Kafka infrastructure and creating topics. This helps to ensure that topics are created in a standardized and consistent manner, and reduces the risk of errors that could be introduced if individual services are allowed to create topics on their own. Additionally it increases the security of your Kafka cluster.

Outlook for the next versions

Although we’ve also published a Spring Boot version of our commons library, sda-dropwizard-commons will stick around. What may be the next goals?

• drop support for Java 11
• update the embedded MongoDB library Flapdoodle to version 4
• update Resilience4J to version 2 (requires Java 17)
• We’re discussing changing the EnabledFieldFilter — Should we remove it? Improve it?

If you have any thoughts on our ideas what we should include in the next major version, feel free to contact and discuss them with us.