4 ms·

> 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?

lvh 9y ago
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.
- desdiv 9y ago
  >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.
  - loevborg 9y ago
    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.
    - timv 9y ago
      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.
  - MBlume 9y ago
    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.
- threeseed 9y ago
  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.
  - lvh 9y ago
    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.

lvh 9y ago

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.

desdiv 9y ago
>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.
- loevborg 9y ago
  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.
  - timv 9y ago
    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.
- MBlume 9y ago
  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.
threeseed 9y ago
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.
- lvh 9y ago
  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.