anchor.diff:  }
   ----
   
  -Once we solved the issue with Cassandra tests, we were mostly done and were ready to use Java 11/17.
  +Once we solved the issue with 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 who to set it up).
  +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 https://openjdk.java.net/jeps/378[text block] is marked as an error in the IDE:
   
   [.centered-image.responsive-image]
  
positive.code: Test using text block in Idea IDE.
  ====
  
  You can manually set Java level to 17, but in this case you may unintentionally use Java > 11 features in non-test code without IDE letting you know.
  Moreover, e.g. Idea reset 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 experience in the discussion!
  
negative.code: <maven.compiler.testRelease>17</maven.compiler.testRelease>
  ----
  
  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.
  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).
  
  === Cassandra connector
  
  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], 
  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.
  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), 
  cleanup fails when it tries to delete the temporary directory with Cassandra files.
  These files were created by a different user with insufficient rights for other users to delete them.
  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.
  