Encountered a weird/interesting issue with Clojure 1.9.0 and uberjars. See #clojure for background. It seems that building an uberjar with Clojure 1.9.0 and :aot :all in Leiningen produces a JAR with these entries

clojure/core__init.class
clojure/core_deftype.clj
clojure/core_deftype__init.class
clojure/core_instant18.clj
clojure/core_print.clj
clojure/core_print__init.class
clojure/core_proxy.clj
clojure/core_proxy__init.class

What JDK did you compile it on? (I believe that was guarded by a when-class conditional)

Java 8. It's all I have installed. I confirmed Robocode runs on Java 8 too (the fact that it tries to load that file confirms that).

Ah, is it possible that core_instant18.clj won't compile standalone? It refers to Inst which is defined in clojure.core...

something very weird is going on there, because the stacktrace has the error coming from the check that load does on the lastmodified time when determining if it should use a compiled class file, or load the source

which it only does if getResource didn't return null

implying that it does exist and it doesn't

FWIW, I can repro in any of my local Leiningen projects using 1.9.0 (in terms of there being no core_instant18__init.class file)

but they load fine, right?

Well, the issue here (I think) is how Clojure is loaded/initialized in Robocode (does something different to how it would be loaded normally via clojure.main etc)?

maybe, hard to say, if I recall Robocode does some sandboxing kinds of things

As far as I can tell, Robocode is just looking to load one class and call methods on it so the initialization path isn't through clojure.main or any of the standard entry points -- and Robocode is doing something dynamic (to load the JAR at runtime) so... ¯\(ツ)/¯

but where the exception comes from indicates that clojure was able to find a resource named clojure/core_instant18__init.class and that the protocol of the resource url is "jar", but that the jar file named in the url doesn't have an entry for clojure/core_instant18__init.class, which sounds like classloader sorcery to me

Yup, definitely something weird going on. But, at the root, why isn't core_instant18__init.class in the uberjar?

I guess the uberjar was built with some java less than 1.8, java 1.6 was the minimum version then, I think

Nope.

I built the uberjars here on my system to repro, using Java 8.

But Clojure 1.9 itself might well have been built on pre-Java 8?

^^^^

(! 934)-> jar tf ~/.m2/repository/org/clojure/clojure/1.9.0/clojure-1.9.0.jar|fgrep core_|sort
clojure/core__init.class
clojure/core_deftype.clj
clojure/core_deftype__init.class
clojure/core_instant18.clj
clojure/core_print.clj
clojure/core_print__init.class
clojure/core_proxy.clj
clojure/core_proxy__init.class
clojure/pprint$add_core_ns$fn__10758.class
clojure/pprint$add_core_ns.class

if it were built on JDK1.8 that file would exist for sure

I wouldn't say missing, it isn't present and it makes sense that it isn't present, because of all that, and it should be ok to not be present, clojure should be fine loading the source code

I guess I'm a bit surprised that building an uberjar on Java 8 doesn't "fill in" the missing .class file from Clojure...

but for some reason in the robocode environment, clojure is being told the classfile does exist, and then being told it doesn't exist when it goes to check the last mode it

lastmod

Anyways, for the curious... the instructions are in the #clojure channel 🙂

my guess is robocode has a classloader that doesn't return null when a resource doesn't exist

https://github.com/robo-code/robocode/blob/f07bec737cdc367cc8ad69f5fc7a50e714132ee3/robocode.host/src/main/java/net/sf/robocode/host/security/RobotClassLoader.java#L428 maybe here

That is one suspect piece of code.

It will return the last url tried, even if that one couldn’t open its connection - yuk.

not to mention totally busted wrt modules

I guess if they’re always planning to run Java 8 that’s not an issue, but yeah…