> it's pretty awful for most things that aren't Java that target the JVM, like Clojure.
Curious, how does jigsaw make things awful for clojure?
Curious, how does jigsaw make things awful for clojure?
- 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.
It's pretty strange that just because Clojure uses SQL's Timestamp (why ?) that it should be a default.
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.
Just curious, why haven't they switched to java.time.LocalDateTime? Java 8 has been out for 3 years now.
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.
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.