Why is Paguro written in Java?

Why isn't Paguro (UncleJim) written in a newer/better JVM language? Doesn't Java make it old-fashioned?

1. Compatibility: A Java-based library is equally usable by all major JVM languages. There are type-safe implementations of these collections in Scala, but it can be really difficult to call Scala from Java. A language like Kotlin could choose to just add a few @NotNull annotations, pop this whole project into their stdlib, and everyone would just assume it had been implemented in Kotlin.
2. Paguro uses code from the Clojure collections which were implemented in Java. This project adds type annotations and cleans up their inheritance hierarchy to make them more attractive in type-safe, Object Oriented languages like Java, Kotlin, and Scala. It should still be equally usable by dynamic languages like Groovy and Clojure, though Clojure has most of this code in it's stdlib already.
3. Writing in Java keeps it small with no dependencies. The Paguro jar is less than 250K. Compiling in Kotlin (for example) would add the kotlin-runtime and kotlin-stdlib which total about 1MB. Some Android developers have said they don't want that.
4. Java (for better or worse) still strives to be the best low-level language on the JVM. It has the fewest layers of abstraction from the bytecode and the most person-hours of testing. That all translates into fewer performance surprises.
5. If I ever implement a programming language called Cymling on the JVM, I want it to be as compatible as possible with all other JVM languages. It will definitely need to share collections, tuples, etc. Implementing them in Java seems better/faster/more-reliable than implementing them in JVM bytecode. Rich Hickey talks about writing a Java collections library before writing Clojure. Sounds like a good idea to me!
6. Java is still tied with JavaScript for Most Popular Programming Language, I think because so much legacy code is written in Java. Java is arguably required for Android development. Using this library works around many of Java's non-functional warts, even (or especially) in Java 8 and therefore lets people program Java (or Kotlin) more like the way they'd write in Clojure, but with types.

All that said, there's a Kotlin version on a branch that may someday replace the Java version, or continue development in parallel.