tools-build 2023-07-12 | Slack Archive

AustinP21:07:47

I'm stumped on a strange uberjar error and hoping someone can provide some insight. Its a Polylith workspace, and we recently updated one of our base namespaces to cleanup some polylith warnings; from workspace/bases/microservice/src/clj/microservice/core.clj to workspace/bases/microservice/src/clj/qualifier/microservice/core.clj. Very minimal change throughout that one base thats being built into the uberjar for this project. Standard way of running for dev, clj -M:run still works great, and building the uberjar seems to work fine, but attempting to run the uberjar throws a ClassNotFoundException for clojure.tools.reader.

Exception in thread "main" java.lang.NoClassDefFoundError: clojure/tools/reader/reader_types$source_logging_push_back_reader
        at hugsql.parser$parse.invokeStatic(parser.clj:261)
        at hugsql.core$parsed_defs_from_file.invokeStatic(core.clj:44)
        at hugsql.core$def_db_fns.invokeStatic(core.clj:530)
        at hugsql.core$def_db_fns.invoke(core.clj:530)
        ....
Caused by: java.lang.ClassNotFoundException: clojure.tools.reader.reader_types$source_logging_push_back_reader
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
        ...

I can roll back to the commit right before this namespace change and it builds and runs just fine, and theres nothing besides the name change in the commit. Any ideas? The only thing I can think of is a classpath issue, but the basis and such is all packaged the same as it was before the name change

hiredman21:07:05

did you update any dependency versions at the same time you made the change?

hiredman21:07:25

is there a clojure/tools/reader/reader_types$source_logging_push_back_reader.class in the uberjar file?

hiredman21:07:02

do you use core.async anywhere?

hiredman21:07:33

what options are you passing to compile-clj?

hiredman21:07:51

are you using :ns-compile with a single main namespace?

hiredman21:07:41

my guess is renaming the namespace changed the order in which namespaces are being aot compiled, which changes the load order, and for some reason now clojure.tools.reader.reader-types is being loaded before/outside the context of aot compilation, so it is not being aot compiled, so the class files are missing when you go to run from the uberjar

AustinP21:07:44

no dependency version changes in between. the reader_types.clj exists in the jar, but no class file (which is the problem).

AustinP21:07:11

we do have core.async in the base, included as a dep, but its not acutally being used

AustinP21:07:15

im using almost exactly the polylith build.clj https://github.com/polyfy/polylith/blob/master/build.clj

hiredman21:07:20

the latest version of core.async does problematic stuff with code loading, but I don't think when that issue is triggered it looks like this

hiredman21:07:46

and shouldn't be an issue if it is never used (maybe if a dep uses it?)

AustinP21:07:43

your guess sounds very right. let me go look at the aot compile stuff and maybe see what could be causing it. because youre right, the clj is there, its just not compiled into a class file

hiredman21:07:20

a common source for libraries getting loaded before they are supposed to is having a user.clj around that is loading them

AustinP21:07:01

yeah the :aot alias does match the updated namespace. the corfield build uber task is doing the compile and bundle together i believe

AustinP21:07:50

oh my god, got it

AustinP21:07:28

it needed a :transitive true in the opts being passed to the uber task

AustinP21:07:43

sean mentions it at the bottom of the build-clj readme for monorepos, but we somehow had it working without it previously, and this namespace change just exposed it with this odd error

seancorfield22:07:49

Yeah, that sort of "knobs and dials" issue is why I've sunsetted build-clj and I recommend people use tools.build directly instead.

AustinP23:07:07

indeed, i ended up at the polylith recommended build.clj trying to migrate off of build-clj, but then realized its still being used in that polylith build file! Going to go through and update the build-clj/uber calls and others to use tools.build instead. Looking forward to an updated recommended polylith build.clj tho eventually!

seancorfield23:07:10

Can you pop into #C013B7MQHJQ and grumble about it? I'm about headed out the door and I'm not even sure if there's a GH issue for it right now.

AustinP23:07:42

will do! Appreciate it

2023-07-12

Channels