gharris1727 commented on PR #14092: URL: https://github.com/apache/kafka/pull/14092#issuecomment-1664298812
> I see, but that's not the case here, we either LATEST_0_9 or DEV_BRANCH. We do not load different module versions at the same time on the classpath, so there is no compatibility boundary to consider. Am I missing something? These commands are being run in the context of a kafka installation with a particular version. The version used is the `node.version` that this condition is based on. The `kafka-run-class.sh` script adds the jars from the installation to the `CLASSPATH`, before finally calling the java runtime. So for example, if the `node.version` is `1.0.0`, this condition will be true, and the script will add DEV jars to `CLASSPATH`. `kafka-run-class.sh` then finds the `1.0.0` jars and adds them to `CLASSPATH`. This means that on the classpath at runtime we should have: * DEV tools * DEV tools-dependant-libs * DEV clients (with your change) * 1.0.0 tools * 1.0.0 tools-dependant-libs * 1.0.0 clients * 1.0.0 core * 1.0.0 everything else When the same jar is present, the classpath is ordered such that the earlier injected `CLASSPATH` jars take precedence, so the `DEV tools` version is the one that is loaded. After all, the ProducerPerformance class depends on the Producer from clients, and this code didn't inject the clients before. And if the original condition didn't fire, then the `CLASSPATH` was left alone, and the final classpath constructed by `kafka-run-class.sh` only had DEV jars on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
