Launch Announcement: How I become an Book Author

"One day, while reading a book, I thought about what it would be like to be an author and write a book myself. This day is here and it is real and here some details of my journey... #java #designpatterns #platform #effectiveness #maintenance #fun #rocks Packt"

  I started working on the book almost a year ago and now it's done! The book is published, all minor tasks are solved and the current state? I'm looking forward to my hardcopies! 

  Now I'm trying to figure out how to properly share how much thoughts I put into creating something that every developer will potentially appreciate on his daily job. Something that could kick her/him back on the trail during being in the local minimum. Maybe not only her/him but also to me just to refresh some points and to keep all knowledge fresh.  I was thinking that maybe even my kids will appreciate it when they grow up, haha.

  Design patterns are a very engaging topic, similar to math. Technologies may change, hardware may change, and we can not stop evolution or time but math remains, similar to the design patterns. They may be adopted differently due to the technology jump but they will be there. 

  The book begins by introducing the Java platform in enough detail to shape the context to understand the value of using patterns. Insights are automatically revealed during usage of presented programming concepts while implementing patterns. 

  I have used neutral examples in the book by using vehicle manufacturing abstractions to drive the reader through the entire book as we all love vehicles. This setup allowed connecting all dots between different design pattern approaches and implementations and to create a flow where the reader may identify himself or herself with the chapter. With all the great Java API’s and all the newly added Java platform enhancements I was inspired  to not use additional frameworks, just pure Java and command-line. I hope the reader appreciates it similarly to me :). In my eyes this allows the reader to stay fully concentrated on the particular topic and apply it across different scenarios. I'll let it upon the reader how successfully I did it. 

  The book contains many standard terms used across the application designers community which makes the book valuable reading material not only for developers but maybe also for project managers to assimilate a similar terminology used across the different types of meetings in different stages of application development. Let's see, it was one of my secret wishes ;)

  Anyhow, after many years of working with multiple languages running on the Java Virtual Machine, my biggest pleasure was always with Java language as the most effective tool to create byte-code. 

  I want to thank my beloved wife, my beautiful kids for giving me energy to step over difficulties and continue my work on this book till the successful end.

It was a great pleasure to work with the Packt team, reviewers  that helped me through this amazing journey. My special thanks goes to Bruno Souza for writing such a beautiful  foreword! 

Thank you guys: Bruno Souza, Sonia Chauhan , Sathya Mohan, Prajakta Naik, Rohit Kumar Singh, Werner Keil and others. 

It was my big pleasure to make this book happen.

Of course I can not forget my peers from the OpenValue family for having some nice discussions with me.

Java Flight Recorder: profiling Kotlin and Java apps with fun

Introduction

The goal of this article is to examine the possibilities of profiling Kotlin and a similar Java application with JMC/JFR to get a better understanding of their behavior compared to each other.

Nowadays the IT world often spells  terms like Site Reliability Engineering - SRE [5] or latencies, but how to measure this in an accurate way without relying on “random” samples ?  The answer to this question is out of the scope, but we can show what possibilities there are for understanding the behaviour of an application based on simple examples. 

Starting slowly: what is the JVM? The JVM stands for Java Virtual Machine. The JVM enables a computer to run Java programs, but not just only them. JVM supports all languages that are able to be compiled into the Java byte-code. All good so far, but what is the JFR ?

The letters JFR stand for the Java Flight Recorder, which is an event-based toolset build directly into the JVM.

Exciting, isn't it ? The JFR can provide a view to the JVM internals through emitted events and more…

The purpose of the article is to compare a Kotlin and a Java app and touch “hidden” compiled code compositions.  

Let’s briefly introduce Koltin as Java is known a bit longer. I bet a couple of million articles have already been written about Java, so it’s fair to have a short Kotlin introduction. 

Kotlin belongs to the JVM language family. It was introduced in 2011 as a new language for JVM and has been developed by JetBrains company. 

The communicated goal was to become “better language” for the JVM. Kotlin has been successfully adopted by the Android community. In short, Kotlin is an object-oriented statistically typed language. It offers a set of quite handy features: data classes, concise, safety, smart casting, functional capabilities etc.  
Aside from the often spelled Kotlin "benefits",  it seems that nowadays more companies are thinking about or are already using a Kotlin stack for backend development. The reason for this may seem obvious but there are different perspectives. Such discussion may turn into the chicken-egg argumentation and it is out of the scope of this article. 

I have put the word "benefits" into the apostrophes intentionally as some nice concepts may look very neat in Kotlin but they may not be as optimized as Java’s counterpart (considering latest Java builds). The Java Ecosystem evolves pretty fast and Java stays the 1st JVM language and also the most optimized one. But nonetheless Kotlin has many nice constructs. Such constructs can help teams move faster without causing unwanted issues. An example of such an issue is the well known NPE  (Null Pointer Exception) .

Let’s profile  

The introduction is done. Let’s now compare the characteristics of a comparable Java & Kotlin apps using the JMC/JFR!

The setup goes first. For each measurement we use the current development state of the JMC/Java Flight Recorder - Early Access [1]. Each measurement is done in a 45 seconds time window. All examples  use OpenJDK 17 [4].

We consider the following 2 examples [2] to get some measurable data: 

• Hot-Methods
• Latencies

Each example uses similar JMC/JFR Events. Such events wrap equivalent sections of the application (Java/Kotlin) to obtain comparable results. The application Threads are also reduced in both cases in order to obtain comparable results. This means any detailed platform configuration is avoided as the goal is to compare basic platform configuration.  

1. Hot-Methods Example

The idea of this simple app is to have two “containers” held by the individual "worker". Those two containers each hold their own collection of numbers. The worker tries to find an intersection of those paired containers (see Img.1. in Kotlin, similar in Java)

Img.1.: example worker code - Kotlin

After running 1st not fixed code for 45 seconds we obtain for the Java app following results (see Img.2.)

Img.2.: Hot-Methods example: Java app - 431 400 events emitted

We repeat this process for the Kotlin version of the similar application for 45 seconds and obtain the following results (see, Img.3.)

Img.3.: Hot-Methods example: Kotlin app - 408 403 events emitted

Let's fix the code for both apps and observe the improvements in throughputs on both sides. We publish only the amount of JFR events that have been emitted. (Img.4.) as this is the identifier of the improvements that have been achieved.

Img.4.: Hot-Methods example Java, Kotlin comparison results

2. Latency Example

The second example is based on getting insights into latency that can be caused by many things. It could be unnecessary garbage collection, network issues or improper synchronization inside the application. In the current example we consider a problematic logger (Img.5.) that has a corrupted method log that is synchronized. It means it forces each tread to wait for it. 

Img.5.: Problematic Logger method

The Kotlin application uses the concept of Mutex (Kotlin Interface, coroutines library) to enforce synchronization. Let's take a look at the measurements. We try to answer the question of how many events can be emitted from the corrupted code in a 45 seconds time window (Img.6.: Java, Img.7.: Kotlin)

Img.6.: Java Problematic logger results, 222 JFR events

When we run the Kotlin application we receive almost identical results (Img.7)

Img.7.: Kotlin Problematic logger result, 222 JFR events

After the fixing a problematic logger we obtain the following results (Img.8.: Java, Img.9.: Kotlin). 

The results show that the blocking issue has been removed.

Img.8.: Java fixed logger, 957 JFR events

How is Kotlin app doing? 

Img.9.: Kotlin fixed logger, 808 JFR events

Conclusion

Watching the results we can observe that the results are almost very comparable. Important to note: the time window for the examples was just 45 seconds and the examples were more set up from a research perspective to highlight a specific issue.  We have seen the possibilities that are provided to us by the Java Platform in order to create our application better and understand the behavior in more detail. Mainly, by demonstrating the possibilities the Java Flight Recorder brought to us. We have also discovered, in a bit more details, a composition of the Kotlin itselves and coroutine framework (asynchronous and non-blocking lib)

 

Stay Tuned 

and Happy JVM coding !  

Stay Tuned 

and Happy JVM coding !

References:

1. Java Mission Control Project
2. JMC-JVM-Lang tutorial: profiling examples for different languages 
3. JMC-tutorial examples by Markus Hirt
4. OpenJDK 17
5. Site Reliability Engineering - SRE