This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-06-09
Channels
- # announcements (1)
- # babashka (14)
- # calva (8)
- # chlorine-clover (3)
- # clerk (6)
- # clj-kondo (27)
- # cljdoc (20)
- # clojars (6)
- # clojure (53)
- # clojure-denver (8)
- # clojure-europe (17)
- # clojure-nl (1)
- # clojure-norway (270)
- # clojure-uk (5)
- # clojurescript (35)
- # community-development (7)
- # cursive (12)
- # datalevin (3)
- # datomic (26)
- # etaoin (23)
- # exercism (1)
- # hyperfiddle (3)
- # java (14)
- # nrepl (2)
- # off-topic (12)
- # pathom (3)
- # portal (44)
- # practicalli (2)
- # reagent (7)
- # releases (1)
- # shadow-cljs (13)
- # timbre (3)
- # xtdb (4)
I'm not sure if there's a better place to ask this, but I'm having some trouble compiling/running under different JDK versions. I'm trying right now to compile something under Java 17 and run on Java 8. I'm using :javac-options ["-target" "1.8" "-source" "1.8"]
in my project.clj
to make sure it's always compiling to Java 8 compatible bytecode, but that doesn't seem to be helping with this problem. I'm getting a NoSuchMethodError
trying to run something that calls the clean
method on a java.nio.ByteBuffer
. This seems really strange to me, because the ByteBuffer is type hinted as such, and this works fine when compiling and running under the same version of Java (8, 11 or 17). But when trying to compile under Java 11 or 17, then run on 8, it's telling me that it can't find the method. Now, it's specifically saying java.nio.ByteBuffer.clean
, so it looks to me like it's never doing the lookup to the parent Buffer
class for that method? Which I'm not sure how to get it make that lookup. Because in Java 8 the clean
method was a member of the parent Buffer
but in Java 9 it was moved to the ByteBuffer
itself. So it's a really weird situation. Anyone know what the best way to solve this would be? I'm feeling like I might need to wrap instances of calls of clean
with a function that, upon first invocation, will eval
the same code with a different type tag? So that it'll know where to do the lookup? Or is there a better way to solve this? I feel like surely there has to be.
you might need to use -release now
instead of -source and -target
can confirm, learned this on clj-yaml and https://github.com/clj-commons/clj-yaml/blob/cb82508538c172684bafeaeaa66fa3e9ebe9b1c5/build.clj#L33-L43.
Thanks @U064X3EF3 and @UE21H2HHD! I'll try that out 👍
@UE21H2HHD can I ask why you're shelling out to java -version
instead of using (System/getProperty "java.version")
?
I might have grabbed to code from a babashka script and not thought about using the jvm system property.
Ahh okay, that would make sense. Just wanted to know if there was some advantage there for some reason. Thanks!
@U0NCTKEV8 sorry, clear is what I meant
@UE21H2HHD changing the flags to use at compile time introduced some other issues, so my solution ended up being to just create wrapper functions that annotate the ByteBuffer
s as just Buffer
, and then replace our callsites with those. Works perfectly fine doing that.
Well, good that you have something that is working for you @U01BH40EA0Z, thanks for sharing your success.