A common way to do it is move the conditional logic into a macro. Then that macro can conditionally return a syntax-quoted form that will be fed into the compiler only if the class is there. BTW instead of posting multiple messages one after the other, it's better to just edit the first one.

Another way is to use clojure.lang.Reflector/invokeStaticMethod.

Macros are going to be resolved at compile-time, and I need to deploy this as a precompiled JAR.

Well, no need to remove and edit now, after I have answered. :) But not a big deal. It's just that with a single message it's fewer notifications to those who have them enabled, and it's easier to link to older threads.

(this is a library shared across couple of other components)

But invokeStaticMethod might be helpful, let me try! 🙂

FWIW, Alex https://clojurians.slack.com/archives/C053AK3F9/p1695054527296809?thread_ts=1695053518.553819&cid=C053AK3F9.

Any alternative for that particular scenario?

You could maybe use eval like this:

(try
  (eval '(java.util.concurrent.Executors/newVirtualThreadPerTaskExecutor))
  (catch clojure.lang.Compiler$CompilerException _
    :fallback))

There might be caveats there, but I'm not sure.

Yeah, eval should be fine. Plenty of usages of that pattern around as well.

I see.

evict is a protocol method of a cache factory. You can write a delegating implementation that will call anything you want. But there's nothing built-in, AFAICT.

Thanks

FWIW, you can do it in 1.12.0-alpha2 without any extra deps: https://clojure.org/news/2023/04/14/clojure-1-12-alpha2#_add_libraries_for_interactive_use

Clojure 1.12.0-alpha4 is the latest version (with an important bug fix for drop). Even before 1.12, I used tools.deps.alpha as a source (git) dep and leveraged the code in that to add dependencies to my running REPL. Also, next.jdbc itself does not depend on slf4j so that conflict is coming from some other dependency in your project:

> clojure -Sdeps '{:deps {com.github.seancorfield/next.jdbc {:mvn/version "RELEASE"}}}' -Stree
Downloading: com/github/seancorfield/next.jdbc/maven-metadata.xml from clojars
org.clojure/clojure 1.12.0-alpha4
  . org.clojure/spec.alpha 0.3.218
  . org.clojure/core.specs.alpha 0.2.62
com.github.seancorfield/next.jdbc 1.3.894
  . org.clojure/java.data 1.0.95
    . org.clojure/tools.logging 1.2.1
  . camel-snake-kebab/camel-snake-kebab 0.4.3

Very strange. First time I used mvn deps:tree and found it does depend on that, now I used it again and it doesn't anymore. I only excluded slf4j with :exclusions (in pomegranate's dependency list) and now slf4j isn't anywhere to be found. Also, the library is buggy anyway, with stray warnings and exceptions. Are logging libraries really that complicated?

SLF4J in particular.

Ah, I understand. Simple is in the name, after all.

Simple doesn't mean easy. :D

(But it's also not that simple as well.)

Yes, a client of mine is creating a client for the CMS that I've written in Clojure. All closed-source though, so no examples. Can't say it's awesome because I strongly dislike Swift and the current state of its ecosystem. You'll also have to use JSON or write your own Transit library (even if my client opens the source of the Swift library for Transit they've written, it's far from being complete).

Not SwiftUI, but you might look at ClojureDart for iOS and MacOS apps; I'm using it, and it's great! The folks who wrote it are super responsive in #C03A6GE8D32 too.

Generally, yes

I guess I've just been lucky in the past, being somewhat cavalier about the JDK used for build and the JDK used for run. I can't repro a simple case of this locally right now but... lesson learned 🙂

You can compile .java to .class with a newer JDK (than the one that will run it) by using the --release flag with javac (or so I read) ... is there a comparable technique to use with Clojure?

Depending on how the uberjar is constructed it may be collapsing a, uh, what is it called a multi-release jar

Where different classes are exposed to different versions of java, and building the uberjar on java version whatever is only including the classes for that version

Ah, I see debugging continued elsewhere

This is using the "default" uber approach in tools.build with no special Java or Clojure compiler options.

I have seen this as well, I am trying to figure out the cause I am guessing it's because my build is using an unpinned container ie clojure:tools-deps where as the compose file is using eclipse-temurin:17 code wise nothing really changed it just topped working, going to try and pin the build to jdk 17 and see if that helps

Ah, this is breaking Jepsen all over the place too. Has anyone worked out a workaround? https://github.com/jepsen-io/jepsen/issues/585

In general, compile with the lowest Java you want to support or use the —release flag when compiling

Huh, even with :javac-options ["--release" "11"] in Jepsen's project.clj, projects that depend on Jepsen as a library explode on any JDKs below 21. 😕

https://clojurians.slack.com/archives/C03S1KBA2/p1697234118933419 has some more debugging info related to this thread (no solution, just more zeroed in on the issue)

Yeah, for me it explodes because of Clojure's built-in rrb_vector.clj https://github.com/jepsen-io/jepsen/issues/585

if you are aot jepsen with a lower jdk it should fix it, but it isn't a javac/java lang issue, so passing flags to javac won't fix it

the clojure compiler is what ends up emitting references to the java.util.SequencedCollection class (something about reifys and default methods, maybe triggered by the introduction of the new interface in the ancestors of List) and the clojure compiler looks at what classes are live and available when it is compiling, no --release or --target or whatever flags for it

Ahhh, right then. I should write up a blog post, it's been impossible to find resources for this.

Right, maybe this will help someone else later: https://aphyr.com/posts/369-classnotfoundexception-java-util-sequencedcollection

Would you (or someone who knows what this is about) recommend a clarification to https://clojure.org/reference/compilation ? I do not see Java version compatibility addressed.

@U038RGYDGUR Your post sounds like you think the Clojure compiler would get a "fix" for this -- but it seems like this is the expected behavior (compile on JDK N, code may require JDK N+ to run). @U064X3EF3 Is a change to the Clojure compiler being considered for this JDK 21-specific issue?

Oh, maybe I misunderstood! I've been compiling on newer JDKs for deployment on older JDKs for a decade using -source and -target , just kinda figured that was normal. I build my libraries on my desktop which runs JDK 21, so I suspect I'm gonna mess this up routinely for the next N years.

There are multiple things here - bytecode version and compiled JDK references. The Clojure compiler for several releases has emitted Java 8 bytecode, regardless of which Java version you are compiling Clojure with (via the embedded ASM), and thus we support Java 8+ at runtime. If you are compiling interop invocations into the JDK, you are implicitly bound to whatever you're using - you can't compile an interop call to a JDK 21 only method and expect it to work at runtime on JDK 17. The subtlety here is that if you use deftype and implement List, you'll have an implicit dependency on their new parent interface SequencedCollection, which has a new method reversed() which comes into the bytecode of the deftype. We had a similar kind of problem when Java added the default overloaded Collection.toArray() in Java 11.

Would it make sense to change rrb_vector.clj?

possibly. that's roughly how we "fixed" this in this place and others last time

(Clojure primitive vectors in gvec have the same issue)

for the toArray case, that was a new method in an existing type extended in a deftype so it could be implemented and then just ignored on older jvms (I think). for this, it's a new method on a new type and that affects the return type of the method emitted into the deftype class (it returns SequencedCollection) so you can't prevent it from getting into the emitted deftype class

in any case, I will take a closer look at this and see if there is something that can be done in the deftype emitter

Thanks for thinkin bout it, Alex. 🙂

logged at https://ask.clojure.org/index.php/13748/java-lang-noclassdeffounderror-java-sequencedcollection

It's a new interface inserted into the hierarchy of List, Deque, LinkedHashMap (and a few other things) so I guess it's pretty easy to run into... https://docs.oracle.com/en/java/javase/21/core/creating-sequenced-collections-sets-and-maps.html

I guess anything that makes instances any of those leaf classes is going to require the new interface is present...

> JAVA_HOME=$OPENJDK21_HOME clj
Clojure 1.12.0-alpha4
user=> (System/getProperty "java.version")
"21"
user=> (ancestors java.util.List)
#{java.util.SequencedCollection java.lang.Iterable java.util.Collection}
user=>

Exception in thread "main" java.lang.NoClassDefFoundError: java/util/SequencedCollection
        at java.base/java.lang.Class.forName0(Native Method)
        at java.base/java.lang.Class.forName(Class.java:495)
        at java.base/java.lang.Class.forName(Class.java:474)
        at clojure.lang.RT.classForName(RT.java:2209)
        at clojure.lang.RT.classForName(RT.java:2218)
        at instaparse.auto_flatten_seq$fn__987.<clinit>(auto_flatten_seq.clj:314)

@U050ECB92 This breaks if compiled on JDK 21 and run on JDK 20:

(let [a (reify java.util.List
            (get [this x] 42))]
    (println (.get a 0)))

the reify bytecode contains two things, a get(x) and an override for the default method: public java.util.SequencedCollection reversed(); Code: 0: aload_0 1: invokeinterface #39, 1 // InterfaceMethod java/util/List.reversed:()Ljava/util/List; 6: areturn

but not the other defaults method spliterator() or sort(Comparator)

reversed is abstract on SequencedCollection

Ah, so that's why my first attempt to repro (messing with ArrayList instances) wasn't enough -- but the reify was. I'm guessing quite a bit of Clojure code out there implements at least one of those interfaces that now requires SequencedCollection. Good to know.

FWIW I ran into exactly the same issue this week

I'll do a bit more testing once I've cleaned up my current "mess"...