anchor.diff:  In the end, the decision was driven by the fact that running a cleanup container is not possible with the Fabric8 plugin.
   Maven doesn't allow to execute different configurations in the same phase 
   and therefore it's not possible to stop the Cassandra container in the `post-integration-test` phase and at the same time run cleanup container in this phase.
  -Testcontainers allow starting and stopping containers programmatically when needed.
  -It also allows to define the images directly in the code, so we don't need any additional `Dockerfile`
  -and cleanup container is just an implementation detail hidden in the test itself.
  +Testcontainers allow starting and stopping containers programmatically when needed, 
  +allows defining the images directly in code so we don't need any additional `Dockerfile`
  +, and cleaning up the container is just an implementation detail hidden in the test itself.
   Having the ability to run the tests directly from the IDE is a nice benefit on top of these things.
   
   The only tricky thing when using testcontainers was that when we tried to remove the files using Docker `cmd` command,
  -testcontainers randomly filed, stating that the container didn't start in spite of the fact that all Cassandra files were actually deleted.
  +testcontainers randomly failed, stating that the container didn't start in spite of the fact that all Cassandra files were actually deleted.
   The container probably ran so fast that it finished before testcontainers noticed it.
  -Finally we solved it by running short `sleep` in the container and executing an additional command in the container which does the cleanup.
  +Finally, we solved it by adding a short `sleep` in the container and executing an additional command in the container which does the cleanup.
   
   The final cleanup code using testcontainers looks like this:
   
  
positive.code: author: vjuranek
  ---
  
  As you probably noticed, we started to work on Debezium 2.0.
  One of https://issues.redhat.com/browse/DBZ-3899[the planned changes] for the 2.0 release is https://issues.redhat.com/browse/DBZ-4949[the switch to Java 11 as a baseline].
  While some Java implementations still supports Java 8 
  (e.g. OpenJDK will be https://access.redhat.com/articles/1299013[supported by Red Hat] till 2026), 
  free Oracle JDK 8 already https://www.oracle.com/java/technologies/java-se-support-roadmap.html[reached end of life]. 
  So it's time to start thinking about using a more recent JDK and the new major Debezium release is a natural milestone when to do the switch.
  
  +++<!-- more -->+++
  
  Since early releases of Debezium 2.0, hopefully from the very first one `Alpha1`, Debezium bits will be compiled to Java 11 byte code.
  Therefore, you will have to use at least Java 11 to run Debezium.
  Also, if you use any of the Debezium bits in your project, you will have to switch to Java 11.
  
  But wait, what does Java 11/17 in the title mean?
  
negative.code: <dramatic pause here>
  
  No, we don't want to scare you.
  We are actually planning to switch to Java 17, but only for the test suite.
  This will allow us to use more recent Java features in the tests, while users still can stay on Java 11.
  
  == Implementation
  