java

concerned-tortoise 2023-06-09T13:58:50.660819Z

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.

Alex Miller (Clojure team) 2023-06-09T14:08:10.127419Z

you might need to use -release now

Alex Miller (Clojure team) 2023-06-09T14:08:29.287029Z

instead of -source and -target

lread 2023-06-09T14:19:11.397189Z

can confirm, learned this on clj-yaml and https://github.com/clj-commons/clj-yaml/blob/cb82508538c172684bafeaeaa66fa3e9ebe9b1c5/build.clj#L33-L43.

concerned-tortoise 2023-06-09T14:21:51.595689Z

Thanks @alexmiller and @lee! I'll try that out 👍

concerned-tortoise 2023-06-09T14:23:58.938939Z

@lee can I ask why you're shelling out to java -version instead of using (System/getProperty "java.version")?

lread 2023-06-09T14:34:58.489099Z

Can't remember at the moment, sorry.

lread 2023-06-09T14:37:12.863209Z

I might have grabbed to code from a babashka script and not thought about using the jvm system property.

concerned-tortoise 2023-06-09T14:38:52.871789Z

Ahh okay, that would make sense. Just wanted to know if there was some advantage there for some reason. Thanks!

lread 2023-06-09T14:40:01.001889Z

Probably shelling here is a silly way to do it. Lemme know if you find otherwise!

2023-06-09T15:44:37.423029Z

There is no clean, you must mean clear

concerned-tortoise 2023-06-09T16:00:06.212349Z

@hiredman sorry, clear is what I meant

concerned-tortoise 2023-06-09T21:10:46.078579Z

@lee 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 ByteBuffers as just Buffer, and then replace our callsites with those. Works perfectly fine doing that.

lread 2023-06-09T21:54:49.414679Z

Well, good that you have something that is working for you @phdumaresq, thanks for sharing your success.