Hacker News Reader

Comment by lvh | Hacker News Reader

Incomplete list:

- As a dynamic language, Clojure uses reflection extensively. Reflection becomes effectively opt-in in Jigsaw-land, breaking tons of Clojure software.

- JDK9 breaks dynamic classpath introspection and modification breaking java.classpath, dynapath (and hence CIDER &c).

- Clojure itself is no longer loadable from the new bootstrap classloader (clojure.inst requires java.sql.Timestamp). This matters, because being in the bootstrap classloader is a significant performance improvement.

View on HN

If the Reflection and SQL libraries are opt in then why doesn't Clojure just mandate that if you want their software to run you need to enable these modules ?

It's pretty strange that just because Clojure uses SQL's Timestamp (why ?) that it should be a default.

That would necessarily move it off the bootclassloader, for one.

Clojure uses it because it's the only sane time instance in the stdlib. It is not an uncommon class to use for that reason; the underlying reason is that j.u.Date sucks.

>clojure.inst requires java.sql.Timestamp

Just curious, why haven't they switched to java.time.LocalDateTime? Java 8 has been out for 3 years now.

Clojure has a fantastic track record of not breaking existing code. Changing clojure's `#inst` to a different class would probably entail such a backward-incompatible change. There are also still people running Java 1.7.

The argument put forward here (and elsewhere) seems to be that

we want Clojure to gain the advantages of being on the bootstrap classloader in Java 9 while still targeting Java 7

That's pretty unconvincing to me. If you're shipping jars that are intentionally compiled against old JREs then you might not get the benefits of new JVM features. Them's the breaks.

One of the benefits of Clojure is that it's Just Another JAR. If you want the to use a new version of the Java language, you have to convince your devops people to deploy a new version of the Java runtime, which may take time. If you want to use the latest version of Clojure, all you have to do is change a dependency in your build, and you can use the latest version of Clojure with Java 6 if need be.

Maybe eventually compatibility with Java 6 will be abandoned, maybe eventually they'll require 8, but the Clojure devs really don't want to do that lightly.

Reply on news.ycombinator.com