If you have worked with any APMs (or other monitoring/observability products) under Java, you might have heard something like: [paraphrased-marketing-text] to track everything from performance issues to errors within your application, just attach the Java Agent to your app and all of your problems are gone [/paraphrased-marketing-text].

You can read things like this in product docs, or blog posts or hear from sales, marketing, and even in conference talks. What I think you can hear less are the trade-offs, so let’s dive a little bit into that.

In mathematics, cardinality is the measure of the number of elements (distinct values) of a set. For example, the set {200,404,503} contains 3 elements so the cardinality of it is 3. But what does “High Cardinality” have to do with (time series) metrics? Glad you asked, the answer is everything. :)

If you did not attend Spring One, here’s a little recap for you (from my perspective).

Keynote Announcements:

• Spring Framework 6.0 and Spring Boot 3.0
• Java 17 baseline
• JakartaEE 9
• Spring Native
• Spring Observability
• The State of Spring 2021 survey results are available

The rabbit hole goes infinitely deep if you want to do latency measurements, benchmarking, and performance testing/tuning/analysis. They are very hard to do right and it is very easy to mess them up. In this post, I would like to show you a very common mistake (that is just 0.000001‰ of the tip of the iceberg) and an extremely simple solution to fix it.

In this article, I would like to show you a couple of confusing things in connection with Java Strings and give you a few suggestions to avoid issues with them. I also prepared a GitHub repo for you where you can find some code that you can use to try the examples out on your own: github.com/jonatan-ivanov/java-strings-demo.

In the previous parts (one, two, three) of the series, I showed you a simple class that has three concurrency issues and I also explained these issues. In this final post, I would like to explain the tests I wrote to show the issues in action. Please let me know if you have any ideas for improving the tests.

In the first part of the series, I showed you a simple class which has three concurrency issues. In the second one, I explained the first issue: Race Condition. In this post, I would like to explain the rest of them. By the end of the series, you will understand their basic mechanism, you will be able to identify them and I will give you a couple of advice on how to fix them.

I wrote a few tests to demonstrate two of the issues, the third one is tough, please let me know if you have any idea how can it be tested. I’m also interested if you have any ideas for improvements for the existing tests because…
…well, keep reading and you will see. :)

In the first part of the series, I showed you a simple class which has three concurrency issues. In this post, I would like to explain the first issue. By the end of the series, you will understand their basic mechanism, you will be able to identify them and I will give you a couple of advice on how to fix them.

The goal of this example-driven series of articles is explaining, demonstrating, and testing (the fun part) the two most frequent (in my opinion) concurrency mistakes in Java (plus an interesting third one), also giving you a few suggestions to fix them.

By the end of the series, you will understand their basic mechanism, you will be able to identify them and I will give you a couple of advice on how to fix them.

This is the third post of a series where I want to give some tips and tricks for the Terminal/CLI.
You might want to check out the first and the second posts. As previously, buckle-up, put your helmet on, grab a … frying pan and have fun.