A guide is needed for interfacing with Java beyond simple method to dot notation interop that only works for the simplest of cases and only with well designed libraries that exposes clean APIs. Most significant projects in Java are built as massive frameworks with all sorts of weird tooling and dependencies. E.g. Minecraft Forge, Android Dalvik. Clojure has this 'small libraries good, big frameworks bad' mentality and expects everyone to be of high calibre software developers. You have to start somewhere and if you are not an Java developer experienced in wrangling with JVM intricacies then anything interesting can't be done with Clojure. You have to spend weeks on the IRC and mailing lists in the hopes of finding someone who either cares to help you with your problem or just builds the bindings for you. The company driving Clojure development (Cognitect) is small so I suppose their hands-off approach can be excused. But the community really need to pick up the slack for users coming to Clojure who are not experienced Java Devs. E.g. Go/C++/Common Lisp developers who wants to integrate a application written in JRuby and built with a custom Groovy Gradle build script with Clojure. For Java this is very common use case since it's the lowest denominator in the JVM. But good luck for Clojure. There is a huge need for a good book on this. Most Clojure books are generally: how to reinvent a web framework, 101 ways to process a text file using Clojure concurrency features and sequences with a dose of functional programming.

Clojure's error messages (or JVM stack traces for better or worse) are infamously terrible compared to similarly "hip" languages like Elm and Rust that have wonderful error messages. (Version 1.10 improved on this area though there's still plenty of room to grow to reach Rust-level of developer UX) It would also be nice to let users know early on when starting to use the language that Clojure libraries needs minimal maintenance and are almost always completely reverse compatible. (Whether this really is good practice or not when most large software projects are 'evergreen' with 'living documentation' is besides the point. A white lie to users won't hurt anyone. It would be terrible if a person reading a blog post on constraint solving in Core.Logic realizes it hasn't seen a major update in 3 years, gives up on Clojure, and ends up using miniKanren in Python instead.)