Closed weavejester closed 3 years ago
Thanks for the heads up, I'm not running the latest JDK yet on my projects.
In general, I'm not quite sure what to do about optional dependencies and load order. Open to suggestions. This has come up before with Datomic's data types, where folks wanted pretty printing for those.
I think the simplest thing to do may be to pull out optional dependencies in to separate namespaces to be required independently, but the ergonomics of that are less than ideal.
I've investigated this a little further and it only occurs in Leiningen REPLs that are started outside of a project, or inside a project marked as :eval-in-leiningen
, which is curious.
I'll investigate further, but as a more general solution for things like Datomic's types, you should be able implement the protocol at runtime iff the class exists. There's an example of it in Ring if you want to take a look.
Hi,
I'm developing a Lein plugin, having released some preliminary versions.
The plugin depends on fipp latest (0.6.3).
We've noticed that the plugin fails due to this issue, if using a JDK > 8:
I'd be greatly thankful if the issue was solved. It should be a matter of splitting the https://github.com/brandonbloom/fipp/blob/3e29a69cd7b93310441efa1de66c98459384ee9c/src/fipp/ednize.clj#L33 into two extend-protocol
s, a large unconditional one for the non-problematic classes, and a conditional one, wrapped in something like (when (try (Class/forName "...") (catch ClassNotFoundException _ false)))
.
Hey @vemv, I'd consider a PR that does as you suggest, but I'm concerned that the issue isn't whether or not the class is available. It's when the class is available. If you load Fipp and then later load the java.sql package, there is no mechanism to properly extend the protocol to that type. Or have I misunderstood the situation? That said, it might be preferable to degrade and solve the problem I'm highlighting later. I don't personally have this issue, so I'm open to suggestions from folks on the right way to proceed.
Thanks for the response! I'll try to determine the exact cause of the issue so that this can be confidently fixed.
...to the best of my knowledge, :import does "nothing" (java classes don't have to be loaded - they're always in the classpath, which is immutable) but it's better to examine those assumptions cautiously.
Perhaps it has something to do with Java's module system.
Edit: this is the relevant issue https://github.com/technomancy/leiningen/issues/2149
fipp's issue is basically an instance of https://github.com/technomancy/leiningen/issues/2149 :
Basically, Lein itself (but not Lein-calculated JVMs), including plugins, have a limited classpath (aka the bootclasspath), which starting from JDK9 does not include java.sql* classes.
Relevant quote from https://github.com/technomancy/leiningen/issues/2149:
I believe this is caused by java 9's module system hiding java.sql.* from the bootstrap classloader, and exposing it via the platform classloader instead (see http://openjdk.java.net/jeps/261, and search for "java.sql" to find the relevant paragraph).
From what I know, nothing in Clojure code can fix this situation - it can only be detected. (This explains why neither Lein or clojure.core do an attempt at "force-loading" java.sql.Timestamp somehow).
Checking the source for clojure.core/import
, one can verify that :import
boils down to a class to Class/forName
with the false
argument (i.e. non-loading: one will use JVM's classloaders instead of Clojure's, and no class initializers will be run)
https://github.com/clojure/clojure/blob/0df3d8e2e27fb06fa53398754cac2be4878b12d1/src/jvm/clojure/lang/Compiler.java#L777-L778 https://github.com/clojure/clojure/blob/0df3d8e2e27fb06fa53398754cac2be4878b12d1/src/jvm/clojure/lang/RT.java#L2224-L2225
tldr, from what I can tell (when (try (Class/forName "...") (catch ClassNotFoundException _ false)))
is harmless - it merely removes a feature when it's not possibly available.
OK, then PR welcome.
Running into this with Java 14 as well
Running into this with Java 14 as well
Opened https://github.com/brandonbloom/fipp/pull/78 now. This fix has worked well for me over the last few months.
In later versions of the JDK (from 11 up I believe), certain classes are not guaranteed to be available, including
java.sql.Timestamp
. This causes an issue withfipp.ednize
: