-
Notifications
You must be signed in to change notification settings - Fork 32
Open
Description
Repro: https://github.com/bevuta/byte-streams-def-conversion-aot-issue
Essentially the same issue as #34 but with tools.deps
and tools.build
instead of Leiningen. The resulting error is the same:
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 @650a1aff)
It's very likely caused by https://clojure.atlassian.net/browse/CLJ-1741, i.e. when first AOT-compiling a namespace which depends on another namespace which contains a def-conversion
call, and then AOT-compiling that namespace itself.
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
Drop type-hints from `assoc-conversion` to work around AOT issue
assoc-conversion
to work around AOT issue #69KingMob commentedon Jul 7, 2023
Update for posterity: it's probably not the same as CLJ-1741, even if it's related. 1741 is a duplicate of of CLJ-1650, but that was fixed in Clojure 1.8, so the timing seems wrong.
KingMob commentedon Jul 7, 2023
Re-opening, because the problem isn't really fixed, we just removed the type hints.
But it's interfering with Eastwood, CircleCI, and automatic deploys.
KingMob commentedon Aug 27, 2023
Update. Now it's flat-out breaking the new HTTP/2 code. What's going on?
DerGuteMoritz commentedon Aug 29, 2023
Ouch! Do you have a repro case to look at somewhere?
KingMob commentedon Aug 29, 2023
No, I think I was confused. I don't think it's AOT-related now.
I think the issue is loading byte-streams in Netty threads that use their own classloader. It gives me a ClassCastException even when Netty finds the class because class identity is tied to classloader.
It just looked a bit like the AOT errors we've gotten in the past.
Right now I'm biting the bullet and trying to decide how best to insert the clj loader into Netty threads. It's become more of an issue with the way ALPN and http2 multiplexing work; we have to do more work in Netty than we did for http1, and that runs a greater risk of needing the clj loader.