anchor.diff:  <maven.compiler.testRelease>17</maven.compiler.testRelease>
   ----
   
  -Please note using `release` option instead of legacy `source` and `target`.
  -When target release is different from the source, using `source` and `target` can cause you unexpected issues.
  +Please note that we're using the `release` option instead of the legacy `source` and `target` options,
  +which prevents the accidental usage of Java APIs not present in the targeted Java version.
   See e.g. Gunnar's blog post https://www.morling.dev/blog/bytebuffer-and-the-dreaded-nosuchmethoderror/[ByteBuffer and the Dreaded NoSuchMethodError] for more details.
   
  -After switching to Java 11, the [Maven Checkstyle plug-in](https://maven.apache.org/plugins/maven-checkstyle-plugin/) and the [ImpSort plug-in](https://code.revelc.net/impsort-maven-plugin/) (a plug-in which takes care of proper import ordering) started to fail.
  +After switching to Java 11, the https://maven.apache.org/plugins/maven-checkstyle-plugin/[Maven Checkstyle plug-in] and the https://code.revelc.net/impsort-maven-plugin/[ImpSort plug-in] (a plug-in which takes care of proper import ordering) started to fail.
   However, bumping their versions to the latest releases has solved all the issues.
   
   This was the easy part.
  -The most difficult part was the Debezium [connector for Apache Cassandra](https://debezium.io/documentation/reference/stable/connectors/cassandra.html).
  +The most difficult part was the Debezium link:/documentation/reference/stable/connectors/cassandra.html[connector for Apache Cassandra].
   
  -=== Cassandra connector
  +== Cassandra Connector Tests
   
  -The Cassandra connector now provides support for Cassandra 3 as well as for Cassandra 4.
  -Cassandra 4 https://cassandra.apache.org/doc/4.0/cassandra/new/java11.html[works with Java 11], 
  +Since link:/blog/2022/04/06/debezium-1.9-final-released/[version 1.9], the Cassandra connector provides support for Cassandra 3 as well as for Cassandra 4.
  +Cassandra 4 https://cassandra.apache.org/doc/4.0/cassandra/new/java11.html[works like a charm with Java 11],
   but running Cassandra 3 with Java 11 is not possible (or at least requires some hacking).
   The existing test implementation for this connector didn't run Cassandra in a container as we do it in tests for all other DB connectors, but instead runs Cassandra in embedded mode, i.e. within the same JVM and process as the tests themselves.
   Therefore if you wanted to run the tests with Java 11 (or 17), tests for the Cassandra 3 connector module would fail.
  +
   The obvious solution is to run Cassandra in a container with Java 8.
   This sounds good, but this approach has one pitfall.
  -The Cassandra connector needs access to Cassandra log files as it reads the dedicated log file to obtain CDC events, so the tests need to access Cassandra files in the container.
  -This can be solved quite easily using a temporary directory, for instance within the `target` directory, and mount it as a volume into the container running Cassandra.
  +The Cassandra connector needs access to Cassandra log files as it obtains CDC events from them, so the tests need to access Cassandra files in the container.
  +This can be solved quite easily using a temporary directory, for instance within the `target` directory, mounting it as a volume into the container running Cassandra.
   Cassandra running in the container can later on use this mounted volume for storing its data.
  +
   The real issue starts when you try to do the cleanup after the tests.
  -As Cassandra runs  in the container under a dedicated user named`cassandra`, which is very likely not present on the test machine (or with a different UID/GID), 
  +As Cassandra runs in the container under a dedicated user named `cassandra`, which is very likely not present on the test machine (or with a different UID/GID),
   cleanup fails when it tries to delete the temporary directory with Cassandra files.
  -These files were created in that temporal directory mounted into the container and not in Docker FS overlay, so that are present in `target` directory.
  -As the files were created by `cassandra` user, which is very likely different user than one who runs the tests, user running the tests has insufficient rights to delete files created by `cassandra` user.
  +These files were created in that temporal directory mounted into the container and not in Docker FS overlay, so that are present in the `target` directory.
  +As the files were created by the `cassandra` user, which is very likely different user than one who runs the tests, user running the tests has insufficient rights to delete files created by `cassandra` user.
   Trying to delete them from Cassandra's container on Cassandra exit in some wrapper script turned out to be quite cumbersome and not very reliable.
  +
   The most promising solution proved to involve starting a second container with the same `cassandra` user with access to the mounted volume and cleaning up the files after the first Cassandra container had already stopped.
   
  -We considered two option for running containers:
  +We considered two options for running containers:
   
   * https://dmp.fabric8.io/[Fabric8 Docker Maven plugin]
   * https://www.testcontainers.org/[Testcontainers]
  
positive.code: We use the Fabric8 plugin in the rest of the project, which suggests to use it also in this case to have uniformity across the project.
  On the other hand, using Testcontainers would make tests more convenient for the developers (who actually use tests after all!),
  as it allows to run the tests directly from IDE without starting the container manually.
  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 a cleanup container in this phase.
  
negative.code:     destroyTestKeyspace();
      cassandra.stop();
  
      GenericContainer cleanup = new GenericContainer(new ImageFromDockerfile()
              .withDockerfileFromBuilder(builder -> builder
                      .from("eclipse-temurin:8-jre-focal")
                      .volume("/var/lib/cassandra")
                      .cmd("sleep", "10") // Give TC some time to find out container is running.
                      .build()))
              .withFileSystemBind(cassandraDir, CASSANDRA_SERVER_DIR, BindMode.READ_WRITE);
      cleanup.start();
      cleanup.execInContainer(
              "rm", "-rf",
              CASSANDRA_SERVER_DIR + "/data",
              CASSANDRA_SERVER_DIR + "/cdc_raw_directory",
              CASSANDRA_SERVER_DIR + "/commitlog",
              CASSANDRA_SERVER_DIR + "/hints",
              CASSANDRA_SERVER_DIR + "/saved_caches");
      cleanup.stop();
  }
  ----
  
  Once we solved the issue with the Cassandra tests, we were mostly done and were ready to use Java 11 in the main Debezium code and Java 17 for our tests.
  
  == Open Issues
  
  We need more battle testing to be sure that everything works well with Java 11/17.
  Your help with testing and bug reports would be very valuable here and more than welcome.
  Currently we are aware of one minor unsolved issue related to the Java update.
  Some IDEs cannot distinguish between `maven.compiler.release` and `maven.compiler.testRelease` (or it's not very clear to us how to set it up).
  For example this test using a https://openjdk.java.net/jeps/378[text block] is marked as an error in the IDE:
  
  [.centered-image.responsive-image]
  ====
  ++++
  <img src="/assets/images/2022-05-04-switch-to-java-11/idea_error.png" style="max-width:90%;" class="responsive-image">
  ++++
  Test using text block in IntelliJ Idea.
  ====
  
  You can manually set the Java level to 17, but in this case you may unintentionally use Java > 11 features in non-test code without the IDE letting you know
  (which admittedly isn't too much of a problem, as the next Maven build, e.g. on CI, would catch that issue).
  Moreover, e.g. Idea resets the code level upon any changes in the `pom.xml` files.
  Have you solved this issue?
  Or do you use an IDE which doesn't have issues with mixing different Java levels?
  Please share your experiences in the discussion!
  