Fantastic! That seems to be working just fine. Thank you for such a prompt fix.

I've also got an updated Aleph 0.6.1 with updated deps, but I think it's going to wait until the new year, since nobody's around... 🎄

Argh, spoke too soon

Looks like I actually have a different problem, it seemed similar

Execution error (ClassCastException) at clj_commons.byte_streams.graph.ConversionGraph/assoc_conversion (graph.clj:117).
class clj_commons.byte_streams.graph.Type cannot be cast to class clj_commons.byte_streams.graph.Type (clj_commons.byte_streams.graph.Type is in unnamed module of loader 'app'; clj_commons.byte_streams.graph.Type is in unnamed module of loader clojure.lang.DynamicClassLoader @157345d0)

Happens when compiling a code base which has a def-conversion . Commenting it out gets rid of the error.

It does use the new clj-commons.byte-streams namespace tho :thinking_face:

will try to come up with a minimal repro and file an issue

OK so far unable to come up with an isolated repro 😕

Are you 100% sure that the new version of the library is on the classpath?

yeah pretty much

no other versions in -Stree or -Spath

Just to be absolutely sure - you use those flags with the right aliases you actually use when running the app, right? When I was facing this issue, I had to use a step debugger and manually and menially go backwards from the problematic call site. But it worked.

Hmmm. Keep us posted

Intermediate update: Looks like I'm running into https://github.com/clj-commons/byte-streams/issues/34 here, i.e. I'm also aot-compiling sources here but using tools.build rather than Leiningen. https://github.com/clj-commons/byte-streams/issues/26 was a similar issue. I think I might be able to come up with an isolated repro now ...

and bingo!

ok whittling down ...

AOT is always error-prone. At least every other year, I run into a problem caused by an AOT uberjar that has competing classes in it that it shouldn’t. It can be hard to debug since it depends heavily on the classpath order, making it intermittent.

Indeed 😕 I think it's an instance of https://clojure.atlassian.net/browse/CLJ-1741

OK found a way to work around it in my original case

@kingmob in https://github.com/clj-commons/byte-streams/issues/34#issuecomment-1138535058 you suggested to re-open that issue if it re-surfaces. Do you want me to put my repro in a comment there or rather make separate issue for it?

Here's the minimal repro: https://github.com/bevuta/byte-streams-def-conversion-aot-issue

@U06GVE6NR Does the use of deftype+ help any? We can reopen the issue and add to it, or start a new issue. Either is fine with me. More importantly, is this something we can fix or workaround? Or is it, at best, a bug in the clojure compiler we should make people aware of?

@kingmob deftype+ doesn't make a difference in this situation alas 😕 Thanks for the idea, tho!

In the light of my latest understanding, I think I would just point to the jira issue in the README, mentioning the error message for discoverability via web search

Will file an issue anyway!

Ah interesting, it doesn't even have to do with a custom type being involved

The type causing trouble is apparently https://github.com/clj-commons/byte-streams/blob/master/src/clj_commons/byte_streams/graph.clj#L25 which also uses deftype+ already

OK: https://github.com/clj-commons/byte-streams/issues/68 -- was actually able to come up with a fix / workaround!

see https://github.com/clj-commons/byte-streams/pull/69