DEV Community: jbebar

🍾 Nouvel article pour la nouvelle année 2022 (en français) sur Reactor RabbitMQ

jbebar — Sun, 02 Jan 2022 17:34:18 +0000

Bonjour à toutes et à tous,

Je vous propose un nouvel article, cette fois en français, sur le blog tech de Lectra.

C'est un article présentant la librairie Reactor et son application au travers de Reactor RabbitMQ :

L'article

Bonne lecture et bonne année 2022 🍾 🎆!

Julien :)

How to read messages reliably from RABBIT MQ broker?

jbebar — Thu, 18 Mar 2021 22:14:31 +0000

What is Rabbit MQ 🐇?

Rabbit MQ is a broker of messages implementing the AMQP protocal. It makes in possible for application to communicate in synchronous as well as in aynchronous way. Each application can subscribe and wait for new messages to arrive.

AMQP involves three main actors: publishers, consumers and the broker.
A publisher is an application that pushes messages to a Rabbit MQ broker.
In the Rabbit MQ broker has two important elements: queues and exchanges binded by routing rules.
When Rabbit MQ receives a message, it will check the routing information of the message and drop it the right queue according to the routing rules. The messages will stay in the queue until an application subscribes to the queue and reads the messages.

In this article I will just talk about the consuming part based on a queue with existing messages and a consumer reading from it, so no need to understand the routing part :).

There are two ways a consumer can read a message from a queue:

auto acknowledgement mode (autoAck): the messages are automatically removed from the queue as soon as they are sent to the consumer, this is
manual Acknowledgement mode (manualAck): the consumer subscribes to a queue, and the messages are removed only when the consumer has sent back an acknowledgement (Ack) back to the broker.

We will experiment these two ways of consuming messages.

A simple consumer example 🧪

Let's see the code of a simple consumer made in Kotlin:



package org.jbebar

import com.rabbitmq.client.ConnectionFactory
import com.rabbitmq.client.Delivery
import java.util.concurrent.CountDownLatch
import java.util.concurrent.TimeUnit
import java.util.concurrent.atomic.AtomicInteger
import kotlin.system.exitProcess

fun main(args: Array<String>) {
    val arguments = args.map { it.split("=") }.map { Pair(it[0], it[1]) }.toMap()
    val autoAck = arguments["autoAck"].toBoolean()
    val qOS = arguments["qos"]?.toInt()
    val processDurationSeconds = arguments["processDurationSeconds"]!!.toLong()
    val countDownLatch = CountDownLatch(10)

    var processedMessageCount = AtomicInteger(0)
    val factory = ConnectionFactory()
    factory.host = "localhost"

    val connection = factory.newConnection()
    val channel = connection.createChannel().apply { qOS?.let { basicQos(it) } }

    val deliveryCallback = { _: String, message: Delivery ->
        val receivedMessage = String(message.body)
        println("Processing : $receivedMessage")
        Thread.sleep(processDurationSeconds * 1000)
        if (!autoAck) {
            println("Acknowledging message $receivedMessage")
            channel.basicAck(message.envelope.deliveryTag, false)
        }
        processedMessageCount.incrementAndGet()
        countDownLatch.countDown()
        println("Processed : $receivedMessage")
    }

    channel.basicConsume("demo-queue", autoAck, deliveryCallback, { _ -> })

    countDownLatch.await(10, TimeUnit.SECONDS)

    println("Processed ${processedMessageCount.get()} messages.")
    exitProcess(0)
}

The first part of this code retrieves the command line arguments that will parameter our consumer:

"autoAck": parameters the way our consumers reads messages, if true it is in auto ack mode, if false we are in manualAck.
"qOS": quantity of outstanding messages, quantity of messages that the broker allows to be unacknowledged for one consumer. Also called the quantity of inflight messages.
This parameter is meaningful only if we are in manualAck mode
"processDuration": This parameter sets the time or application takes to process each message. It is not related to rabbit mq configuration, but it is a way to simulate a lagging consumer or a fast one.



    val autoAck = arguments["autoAck"].toBoolean()
    val numberOfMessagesToProcess = arguments["numberOfMessagesToProcess"]?.toInt() ?: 1
    val qOS = arguments["qos"]?.toInt()
    val processDuration = Duration.ofSeconds(arguments["processDurationSeconds"]?.toLong() ?: 0L)

We create connection based on the Qos passed earlier:



    val factory = ConnectionFactory()
    factory.host = "localhost"
    val connection = factory.newConnection()
    val channel = connection.createChannel().apply {
        qOS?.let { basicQos(it) }
    }

In this deliveryCallback, we simulate a business process and pass it to the channel which will consume from a queue called "demo-queue".



     val deliveryCallback = { _: String, message: Delivery ->
        val receivedMessage = String(message.body)
        println("Processing : $receivedMessage")
        Thread.sleep(processDurationSeconds * 1000)
        if (!autoAck) {
            println("Acknowledging message $receivedMessage")
            channel.basicAck(message.envelope.deliveryTag, false)
        }
        processedMessageCount.incrementAndGet()
        countDownLatch.countDown()
        println("Processed : $receivedMessage")
    }

One important part of the code is the CountDownLatch.
It prevents our application from exiting before receiving straight after it launched as it blocks and exits only on two conditions:

countDownLatch.countDown() has been called 10 times, that means 10 messages have been processed.
it passes a duration of 10 seconds

You can see the full code here :).

Let's try our consumer 🧪 !

3 steps:

1 Launch the rabbit Mq broker (check the admin interface on http://localhost:15672/#/ )



docker run -d --rm --hostname my-rabbit --name rabbit-broker -p 5672:5672 -p 15672:15672 rabbitmq:3-management

2 Build and launch the publisher to publish 10 messages:



git clone https://github.com/jbebar/rabbit-mq-sample-sender.git
mvn clean package
java -jar target/amqp-sender-jar-with-dependencies.jar 10

You should see the queue in the admin interface of rabbit mq, if you go in the detail of the queue you will see this:

3 Build and launch the app:



git clone https://github.com/jbebar/rabbit-mq-sample-receiver.git
mvn clean package
java -jar target/amqp-consumer-jar-with-dependencies.jar autoAck=true processDurationSeconds=0

Out put:



Processing : Message 1
Processed : Message 1
Processing : Message 2
Processed : Message 2
Processing : Message 3
Processed : Message 3
Processing : Message 4
Processed : Message 4
Processing : Message 5
Processed : Message 5
Processing : Message 6
Processed : Message 6
Processing : Message 7
Processed : Message 7
Processing : Message 8
Processed : Message 8
Processing : Message 9
Processed : Message 9
Processing : Message 10
Processed : Message 10
Processed 10 messages.

The process is fast enough to consume all messages before the 10 seconds time out.
But if we try with a business process duration of 5 seconds:



java -jar target/amqp-consumer-jar-with-dependencies.jar autoAck=true processDurationSeconds=5

Processing : Message_1
Processing : Message_2
Processing : Message_3
Processed 2 messages.

Our consumer has time to process only two messages before application exits and the queue is now empty meaning we lost 8 messages before they could be processed by our service.
Our consumer had all its messages in memory and they vanished when it shutdown.

In real life scenario this is dangerous: what if a payment service missed a payment because the service restarted or because our application simply crashes?

Using manual ack and Qos to the rescue

Manual ack



java -jar target/amqp-consumer-jar-with-dependencies.jar autoAck=false processDurationSeconds=5

Processing : Message_1
Acknowledging message Message_1
Processed : Message_1
Processing : Message_2
Acknowledging message Message_2
Processing : Message_3
Processed 1 messages.

If we look at the history of our queue we have 9 messages remaining, no more losses.
The broker behaviour with manualAck is to requeue the messages that have not been acknowledged after a certain period of time or because of a consumer disconnection.
In our case, our consumer was delivered all the messages, that's why the number of messages ready drops suddenly, then we had time to process just one of them and send the ack.
The message was then removed from the queue by the broker.
Finally, the number of ready messages goes back up to 9 because rabbit mq sees the connexion is lost with the consumer as the consumer shutdown.
You can see in the following graph, first the ready messages are dropping in favor of the unacknwoledged messages going up. Then when the consumer disconnects, the number of ready messages for other consumers goes back up.

Setting the Qos

The Qos limits the number of messages unacknowledged for a given consumer. This means it limits the number of messages buffered in the memory of the consumer and not yet processed.
This a way to protect our consumer from crashing permanently when reading from a queue with many messages. Also, if the consumer is too long to ack the messages, they are not available for other consumers.

The optimal value depends on the capacity of the consumer, the documentations advices a Qos from 100 to 300 :

qos-value-documentation

To continue this article, an interesting experiment would be to upload a large amount of messages to the queue, reduce the memory available for a our consumer and see at which Qos it will explode 💥 🤓.

Thanks for reading and feel free to comment or ask any question.

🔍 Kotlin: Let's look at inline classes bytecode 🔍

jbebar — Sun, 17 Jan 2021 16:48:37 +0000

Inline classes aim to reduce the overhead due to boxing of primitives. Inline classes are experimental since kotlin 1.3.
You can use them without warning with the following configuration added to the kotlin-maven-plugin, for instance in maven:

    <plugin>
        <groupId>org.jetbrains.kotlin</groupId>
        <artifactId>kotlin-maven-plugin</artifactId>
        <version>1.4.21</version>
    ...
        <configuration>
            <args>
                <arg>-Xinline-classes</arg>
            </args>
        </configuration>
    ...
    </plugin>

The inline keyword means the compiler will replace wherever possible the wrapper class by its enclosing primitive.
Let's have a look at this piece of code:

fun main() {
    val age = Age(18)
    val weight = Weight(87)
    println("Hello I am ${age.value}, my weight is ${weight.value} !")
}
class Age(val value: Int)
inline class Weight(val value: Int)

Using intellij idea we can see the byte code generated by the main method by putting our cursor in the main function and searching the action ByteCode viewer, we obtain:

LINENUMBER 2 L0
    NEW Age
    DUP
    BIPUSH 18
    INVOKESPECIAL Age.<init> (I)V
    ASTORE 0
   L1
    LINENUMBER 3 L1
    BIPUSH 87
    INVOKESTATIC Weight.constructor-impl (I)I
    ISTORE 1
   L2
    LINENUMBER 4 L2
    NEW java/lang/StringBuilder
    DUP
    INVOKESPECIAL java/lang/StringBuilder.<init> ()V
    LDC "Hello I am "
    INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
    ALOAD 0
    INVOKEVIRTUAL Age.getValue ()I
    INVOKEVIRTUAL java/lang/StringBuilder.append (I)Ljava/lang/StringBuilder;
    LDC ", my weight is "
    INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
    ILOAD 1
    INVOKEVIRTUAL java/lang/StringBuilder.append (I)Ljava/lang/StringBuilder;
    LDC " !"
    INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
    INVOKEVIRTUAL java/lang/StringBuilder.toString ()Ljava/lang/String;
    ASTORE 2
    ICONST_0
    ISTORE 3
    GETSTATIC java/lang/System.out : Ljava/io/PrintStream;
    ALOAD 2
    INVOKEVIRTUAL java/io/PrintStream.println (Ljava/lang/Object;)V
   L3
    LINENUMBER 5 L3
    RETURN
   L4
    LOCALVARIABLE weight I L2 L4 1
    LOCALVARIABLE age LAge; L1 L4 0
    MAXSTACK = 3
    MAXLOCALS = 4
  // access flags 0x1009
  public static synthetic main([Ljava/lang/String;)V
    INVOKESTATIC MainKt.main ()V
    RETURN
    MAXSTACK = 0
    MAXLOCALS = 1
}

Not very sexy 😱 right? Even without being a byte code expert let's decrypt the structure first:

We can recognize the different parts of our main function. From LINENUMBER 2 to LINENUMBER 4 we can see the declaration of age and weight variable.
From LINENUMBER 4 to LINENUMBER 5 we can see the invocation of the println function and the use of the java/lang/StringBuilder which is how a template string from Kotlin in translated into bytecode.

If we look again at the declaration of variables:

LINENUMBER 2 L0
    NEW Age
    DUP
    BIPUSH 18
    INVOKESPECIAL Age.<init> (I)V
    ASTORE 0
   L1
    LINENUMBER 3 L1
    BIPUSH 87
    INVOKESTATIC Weight.constructor-impl (I)I
    ISTORE 1
   L2

We notice the two variables declaration are similar:

first: a value is pushed on the stack, with the BIPUSH 18 in the case of the age and 87 in the case of the weight command,
second: the constructor is invoked with INVOKESTATIC for the inline class weight and INVOKESPECIAL for the class Age.
third: a step of storage into the variable pool of the thread is done with ISTORE 0 for weight variable and ASTORE 1 for Age variable.

Let's focus on what makes the difference now:

We use ASTORE in the case of the Age variable and ISTORE in the case of the weight variable. If we go on this reference
of bytecode instructions for java, we can see that commands prefixed by A deals with references to object whereas I deals with integer.
So ASTORE 0 command designates the storage of an object reference at index 0 of the local variables of the thread, that's how the reference to the Age object is stored.
On the other hand, our Weight object doesn't exist in the byte code, it is directly stored at index 1 with the type integer, that is why we have ISTORE 1 instruction.

The StringBuilder calls confirms this replacement of the reference with a primitive:

LDC ", my weight is " INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder; ILOAD 1 INVOKEVIRTUAL java/lang/StringBuilder.append (I)Ljava/lang/StringBuilder; LDC " !"

The call to the integer primitive value stored at index 1 is made with ILOAD 1, so no object reference is used there either.

Another interesting thing to do is to replace the weight class with an integer, and see that the generated bytecode is very close from the one shown above. The main difference we will see are the static calls to the constructor of Weight INVOKESTATIC Weight.constructor-impl (I)I will not be in the bytecode anymore.

Conclusion

With the inline keyword, the kotlin compiler replaces in the bytecode the object reference with the primitive type being boxed.
The point of this is to reduce memory consumption while keeping the advantage of value classes for readability and domain design.
In some cases, though, the compiler doesn't replace the inline class with the primitive type, for instance if more than one property is boxed.
Why looking through the bytecode? Just out of curiosity :), I could also have used the decompiler plugin from intellij to decompile the bytecode into java code to see that the inlined class is indeed replaced, I let you try ;)

Sources:

For more details about inline classes: the kotlin documentation https://kotlinlang.org/docs/reference/inline-classes.html
To deep dive more into how java byte code is written, this article is useful : http://arhipov.blogspot.com/2011/01/java-bytecode-fundamentals.html
Wikipedia reference of bytecode instructions : https://en.wikipedia.org/wiki/Java_bytecode_instruction_listings

Native CLI with Picocli and GraalVM

jbebar — Thu, 20 Aug 2020 18:06:47 +0000

Situation

Let's imagine a CLI which takes as parameters option a client name and selects a random beer for this person, example:

./beer ---name "Jean-Michel"
Let's see what the barman found....
Hey Jean-Michel, you should try: Strong IPA

The CLI is written in Kotlin and uses Picocli to generate a standard help menu and to parse command line options. I will not detail Picocli in this post but the build process of an executable.

Why Graal VM?

If we run this CLI using a jar packaging and java command we have two downsides:

startup time of the JVM, users will not want to wait to order their beer.
ask the user to install a JVM in the right version
the command to launch the CLI will look like java -jar name-of-the-cli.jar whereas we would expect a simple command like this name-of-the-cli.

That's where GraalVM can save us here, it can compile directly java byte code down to binaries for a particular machine (Linux in our example):

No more JVM to install for our users
Almost no startup time
A simple command, as we just have to call the executable file from command line.

GraalVM is a polyglot VM to run many languages (Java, Kotlin among many others) in an optimized way. GraalVM can also be used as a JDK if you develop in Java/Kotlin to compile to Java bytecode.

It comes with the native-image tool can be installed on top of GraalVM to build natives executables from java bytecode.
For this purpose, GraalVM needs to anticipate any runtime reflections operations done, for instance, by the Picocli library. This special compilation is called ahead of time. Every annotation used at runtime in our code will need to come with it's configuration file. These configurations files can be done manually, but usually frameworks provides tools to generate them. Fortunately, that's the case for Picocli.

Adapt our configuration to generate GraalVM configuration files:

Our only source file is the following, we won't need to adapt it but let's keep it here for our understanding:


package org.jbebar.beer.picocli

import picocli.CommandLine
import picocli.CommandLine.Command
import picocli.CommandLine.Option
import java.util.concurrent.Callable


@Command(
    name = "beer",
    mixinStandardHelpOptions = true,
    version = ["beer 0.0.1"],
    description = ["Chooses a random beer for you."]
)
internal class BeerCallable : Callable<Int> {

    @Option(names = ["-n", "--name"], required = false, description = ["Your name."])
    var name: String = "John Doe"

    @Throws(Exception::class)
    override fun call(): Int {
        val beers = listOf("Black IPA Beer", "Light Blond", "Strong IPA", "Red Beer", "White Beer")
        println("Let's see what the barman found....")
        println("Hey $name, you should try: ${beers.shuffled().first()} !")
        return 0
    }

    companion object {
        @JvmStatic
        fun main(args: Array<String>) {
            val exitCode: Int = CommandLine(BeerCallable()).execute(*args)
            System.exit(exitCode)
        }
    }
}

Our initial build.gradle looks like this:


plugins {
    kotlin("jvm") version "1.3.72"
}

group = "org.jbebar"
version = "1.0-SNAPSHOT"

repositories {
    mavenCentral()
}

dependencies {
    implementation(kotlin("stdlib-jdk8"))
    implementation("info.picocli:picocli:4.5.0")
}

tasks {
    compileKotlin {
        kotlinOptions.jvmTarget = "1.8"
    }
    compileTestKotlin {
        kotlinOptions.jvmTarget = "1.8"
    }
}

To use the configuration files generators for picocli library we need to add these lines to our build.gradle.kts :

plugins { kotlin("kapt") version "1.3.72" } : this will enable annotation processing for kotlin.
dependencies { kapt("info.picocli:picocli-codegen:4.5.0") } : Using annotation processing from kotlin during java compilation, it will scan for picocli annotations and generate the corresponding configuration files for graalVM.
kapt { arguments { arg("project", "${project.group}/${project.name}") } } : this will give the jar a unique name and prevent shading from other jars in the case of a uber jar.

After adapting our build.gradle and running gradle clean build we can see the following structure in the generated jar:

If we have a look closer, only one configuration file is filled, the reflect-config.json. It refers to the runtimes annotations used by our code and picocli dependency: the field annotated in their class are detailed in the config.

[
  {
    "name" : "org.jbebar.beer.picocli.BeerCallable",
    "allDeclaredConstructors" : true,
    "allPublicConstructors" : true,
    "allDeclaredMethods" : true,
    "allPublicMethods" : true,
    "fields" : [
      { "name" : "name" }
    ]
  },
  {
    "name" : "picocli.CommandLine$AutoHelpMixin",
    "allDeclaredConstructors" : true,
    "allPublicConstructors" : true,
    "allDeclaredMethods" : true,
    "allPublicMethods" : true,
    "fields" : [
      { "name" : "helpRequested" },
      { "name" : "versionRequested" }
    ]
  }
]

If we check the rentention policy of these annotations, we see that @Option has RUNTIME retention on our field name of class BeerCallable.

Same for the AutoHelpMixin class.

Install GraalVM

To install GraalVM, I let you refer to the documentation for your platform. GraalVM needs C/C++ compilation tools to build the native-images.

After installing GraalVM you can run:

gu install native-image

Compile to native code

Before compiling to native code, it is good to check our application is running using java command, gathering all the dependencies and the source jar in the same folder and use the --classpath or -cp option like this:


java -cp annotations-13.0.jar:kotlin-stdlib-1.3.72.jar:kotlin-stdlib-common-1.3.72.jar:kotlin-stdlib-jdk7-1.3.72.jar:kotlin-stdlib-jdk8-1.3.72.jar:picocli-4.5.0.jar:beer-picocli-1.0-SNAPSHOT.jar org.jbebar.beer.picocli.BeerCallable

Be careful about putting the source file containing the Main class as last dependency in the list passed to -cp. The only argument to pass on top of the option is the name of the class containing the main method.

This will give the following output:

Let's see what the barman found....
Hey John Doe, you should try: Red Beer !

Now, to compile we can stay in the same folder containing our dependencies and CLI jar and run:

native-image -cp annotations-13.0.jar:kotlin-stdlib-1.3.72.jar:kotlin-stdlib-common-1.3.72.jar:kotlin-stdlib-jdk7-1.3.72.jar:kotlin-stdlib-jdk8-1.3.72.jar:picocli-4.5.0.jar:beer-picocli-1.0-SNAPSHOT.jar -H:Name=beer org.jbebar.beer.picocli.BeerCallable

where -H:Name=beer is the name of the generated executable.

Execution


./beer -h
Usage: beer [-hV] [-n=<name>]
Chooses a random beer for you.
  -h, --help          Show this help message and exit.
  -n, --name=<name>   Your name.
  -V, --version       Print version information and exit.
./beer -n "Jean-Michel"
Let's see what the barman found....
Hey Jean-Michel, you should try: Strong IPA !

We can also compare the execution times :


time java -cp annotations-13.0.jar:kotlin-stdlib-1.3.72.jar:kotlin-stdlib-common-1.3.72.jar:kotlin-stdlib-jdk7-1.3.72.jar:kotlin-stdlib-jdk8-1.3.72.jar:picocli-4.5.0.jar:beer-picocli-1.0-SNAPSHOT.jar org.jbebar.beer.picocli.BeerCallable
Let's see what the barman found....
Hey John Doe, you should try: Black IPA Beer !

real    0m0.316s
user    0m0.473s
sys 0m0.060s

With graal VM we can see that the real time is nearly 8 times faster.


time ./beer
Let's see what the barman found....
Hey John Doe, you should try: Black IPA Beer !

real    0m0.044s
user    0m0.006s
sys 0m0.005s

Don't take this "8 times" for granted, of course, it will depend on the type of program you run. But this gives a good idea of how fast it is. The user will not see the difference between this or any system command run from terminal, and that's kind of magical.

To see even more the difference, it could be interesting to run this with programs manipulating larger sets of data.
I hope now our client will not wait to know which beer to drink and take it right out of the fridge.
More seriously, would you now try GraalVM and Picocli combination? Or do you have any other way of writing your CLI apps? Feel free to comment :) and see you soon.

Efficiently manage dependencies thanks to maven BOM

jbebar — Sun, 02 Aug 2020 20:13:44 +0000

Situation

Imagine having several applications using maven for dependency management. You have to make sure all these applications remain consistent in their dependency versions.
For instance, if these applications use a shared database server like mongo db, you want to be sure they are all up to date with mongo db API or they will break.
Updating all these applications can take a lot of your time, also you may have many other dependencies to maintain: security, plugins etc...

Solution: Use a Maven BOM

BOM stands for Bills Of Materials. A BOM gather multiple versions of dependencies and can be imported in your application POM.
BOM dependencies:

will override all the transient dependencies versions of your project.
will be overriden by direct dependencies.

Let's take an example with dependencies of one of our CLI app:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.jbebar</groupId>
    <artifactId>my-cli-app</artifactId>
    <version>1.0-SNAPSHOT</version>
    <dependencies>
        <dependency>
            <groupId>org.mongodb</groupId>
            <artifactId>mongodb-driver-sync</artifactId>
            <version>4.1.0</version>
        </dependency>
        <dependency>
            <groupId>info.picocli</groupId>
            <artifactId>picocli</artifactId>
            <version>4.4.0</version>
        </dependency>
    </dependencies>
</project>

Let's create a BOM to manage these two dependencies, and also spring jdbc as it is used in other of our CLI apps and we need to share this BOM:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.jbebar</groupId>
    <artifactId>sample-BOM</artifactId>
    <version>1.0.0</version>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.mongodb</groupId>
                <artifactId>mongodb-driver-sync</artifactId>
                <version>4.1.0</version>
            </dependency>
            <dependency>
                <groupId>info.picocli</groupId>
                <artifactId>picocli</artifactId>
                <version>4.4.0</version>
            </dependency>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-jdbc</artifactId>
                <version>5.2.8.RELEASE</version>
            </dependency>
        </dependencies>
    </dependencyManagement>
</project>

Let's now add this BOM in dependency management section of our app with the type pom and the scope import and remove the versions of our dependencies.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>org.jbebar</groupId>
    <artifactId>my-cli-app</artifactId>
    <version>1.0-SNAPSHOT</version>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.jbebar</groupId>
                <artifactId>sample-BOM</artifactId>
                <version>1.0.0</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <dependency>
            <groupId>org.mongodb</groupId>
            <artifactId>mongodb-driver-sync</artifactId>
        </dependency>
        <dependency>
            <groupId>info.picocli</groupId>
            <artifactId>picocli</artifactId>
        </dependency>
    </dependencies>
</project>

We notice our versions are the same has in the maven BOM we created after running mvn dependency:tree or checking in our IDE. The BOM settles the dependencies versions for us.

Also, if we change the version of Picocli to 3.3.0 in the project POM, maven will prioritize the direct dependencies versions and not take the BOM version of picocli into account, we can run a mvn dependency:tree to see this:

[INFO] org.jbebar:my-cli-app:jar:1.0-SNAPSHOT
[INFO] +- org.mongodb:mongodb-driver-sync:jar:4.1.0:compile
[INFO] | +- org.mongodb:bson:jar:4.1.0:compile
[INFO] | - org.mongodb:mongodb-driver-core:jar:4.1.0:compile
[INFO] - info.picocli:picocli:jar:3.3.0:compile

Moreover, the jdbc dependency is not present. That is why it is common to see BOM's with dozens of dependencies. The spring boot BOM is a good example.

Example of commonly used BOM: the spring boot BOM

To see the list of dependencies managed by spring boot you can have a look here It manages spring dependencies as well as other dependencies (ex: kotlin coroutines, mongo db driver).

Another good reason to use this BOM is to avoid inconsistency between spring dependencies.
As said at the beginning, the BOM overrides transient dependencies.
Two springs dependencies can be present as two transient dependencies, for instance it can come from dependency A and dependency E:

A -> B -> C:2.0.0

E -> C:1.0.1

In that case, C will be in version C:1.0.1. This makes it hard to know which dependency is chosen.
Above all it can lead to unexpected issues, what happens if dependency C is shared and needs to be at least in 2.0.0 for a given dependency but is set at 1.0.0 by a more direct dependency?
Using the spring boot BOM prevents from these issues between spring dependencies as it overrides all the transient versions.

Thanks for reading, any suggestions are welcome :).