As another Clojure programmer, I say you should care about developments in Java. After all, the Java module system is precisely why classes became minefields with clojure.core/bean -- illegal reflective accesses and what not.
As someone else noted in this comment section, a lot of useful Clojure libraries are wrappers over Java libraries. So improvements to Java used in these libraries are good for you, too.
The Java module system is a problem on Java as well. They defined "module" in the narrowest terms possible (API visibility) without addressing any of the modularization problems Java developers have to deal with every day, so we end up with another layer on top of the layers of third-party dependency management systems, package repositories, and runtime class loaders that we are forced to use to have a semblance of a working build and deployment toolchain. They could have expanded upon this foundation and came up with the equivalent of Cargo or go modules, but instead they created this n+1 standard that 90% of developers either ignore or disable.
> They defined "module" in the narrowest terms possible (API visibility) without addressing any of the modularization problems Java developers have to deal with every day
What other way would be possible, how would you solve it?
As someone else noted in this comment section, a lot of useful Clojure libraries are wrappers over Java libraries. So improvements to Java used in these libraries are good for you, too.