What happens in my experience is that Clojure programs do tend to encapsulate more extensive use of Java interop into their own modules. For more standard or commonly used packages, this means a canned library or similar. (But this notion of abstracting out APIs is just good software engineering in general, and not really specific to Clojure or anything else.)
1. If you need it, and there's not a Clojure alternative, you don't have to write your own. 2. If you have any proprietary .jars or anything like that, you can leverage those services, models, etc when building an existing Clojure app. This is mainly a transition-type thing, in my experience. "Well, we could try Clojure but then we cant reuse any of our existing models." Not entirely true. However, you probably will want to change those from mutable classes pretty quickly :)
Don't get me wrong, Clojure is a great language in itself, but the lack of libs make you spent 90% of your time writing interop, you start to ask yourself if it's worth the trouble.
https://github.com/finalfantasia/apache-spark-examples-in-cl...