Cannot load fipp in Java 9 using bootclasspath #60
Comments
|
Try using: Leiningen uses the bootclasspath by default in 2.9.0. Loading Related Clojure ticket: CLJ-2077. The patch for that ticket means Relevant Leiningen commit: technomancy/leiningen@c0eb388 |
|
so should clojure fix this or leiningen ? |
|
Seems like this is unrelated to Fipp. Closing. |
|
PR #65 mentions bootclasspath, but it's unclear if that has anything to do with the issue of whether or not clojure.instant has been loaded. To ensure that clojure.instant gets loaded, I've just pushed this commit: Please test the newly published version 0.6.19 and let me know if the problem is resolved. If it is not resolved, please let me know:
|
|
@brandonbloom So if you're using bootclasspath in a post-Java 9 world, You can refer to https://clojure.atlassian.net/browse/CLJ-2077 for confirmation - the workaround placed in clojure.core simply stops trying to load With that in mind, you actually can't ensure that |
|
The reason we care about the behavior of bootclasspath is that at least for the moment, Leiningen still uses it. You can pass |
brandonbloom
changed the title
|
Thanks for the link to CLJ-2077, that clears things up for me. I'm not sure I like the
Considering that it looks like bootclasspath is going away, is there any good reason why anything should rely on this behavior? Is there any meaningful disadvantage to setting |
This is true, but I'd argue that in that case it's the responsibility of the party engaged in dynamic classloading to handle the classloading order in such a way as to achieve the necessary outcome. Dynamic classloading is black magic and the parties engaged in it typically know that there might be dragons.
Is bootclasspath going away? I've only read about libraries getting removed from it, not it going away entirely (I'm not staking a position here, I just literally couldn't find a thread where its absence wholesale was discussed). Lein continues to rely on bootclasspath because not using it slows down Lein initialization time by about 30%. For them, moving away from bootclasspath would have a negative startup time impact on all of their users, even those who wouldn't otherwise have been affected by bootclasspath issues. Particularly relevant since they like having backwards compatibility to Java 8. For me (selfishly, as the Ultra maintainer), I see two disadvantages to setting |
Quoting from the JDK 9 Release Notes:
Thanks for taking the time to provide your perspective, but for the following reasons I'm not going to fix this issue:
Let me know if I've grossly misunderstood something. |
|
I think your position is fair. Structurally this is a very complex domain with legitimate motivations for everyone acting. The JDK folks want to minimize attack surface area. The Lein folks want to minimize startup time. The Clojure folks want to maintain backwards compatibility. The ecosystem in which this problem exists is one that doesn't lend itself to a clean solution, at least for now. Fipp doesn't need to support weird runtime configuration environments. #65 was the lowest-impact change that could have been proposed to accommodate said runtime configuration environments, but I understand why that's not enough to justify merging it. |
An ultra dep is causing issues with jdk 9+
venantius/ultra/issues/108
The offending dep is not willing to change because ultra is relying on a
feature that is only present in jdk 8, and has since been removed
brandonbloom/fipp/issues/60
An ultra dep is causing issues with jdk 9+
venantius/ultra/issues/108
The offending dep is not willing to change because ultra is relying on a
feature that is only present in jdk 8, and has since been removed
brandonbloom/fipp/issues/60
Because I ran into this: brandonbloom/fipp#60
Hello,
I'm trying to install
ultrawhich depends onfippbut I'm getting the following error:I have the following environment:
I see someone already reported the problem on the ultra repo.
I'm totally new to Clojure so I may be missing to important infos here so let me know if you need anything else.
The text was updated successfully, but these errors were encountered: