This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-26
Channels
- # aws-lambda (15)
- # babashka (7)
- # beginners (124)
- # calva (7)
- # cider (19)
- # clj-kondo (26)
- # clojure (261)
- # clojure-australia (3)
- # clojure-dev (10)
- # clojure-europe (45)
- # clojure-nl (4)
- # clojure-uk (6)
- # clojurescript (10)
- # datomic (7)
- # depstar (7)
- # emacs (11)
- # fulcro (41)
- # graalvm (48)
- # helix (1)
- # honeysql (17)
- # inf-clojure (7)
- # introduce-yourself (3)
- # jackdaw (2)
- # lsp (36)
- # malli (2)
- # meander (2)
- # membrane (1)
- # missionary (11)
- # off-topic (17)
- # pathom (83)
- # polylith (15)
- # re-frame (31)
- # reagent (42)
- # sci (35)
- # shadow-cljs (13)
- # spacemacs (13)
- # sql (19)
- # timbre (3)
- # tools-deps (77)
Hi, I'm trying to compile my web app with graalvm. The compilation succeed, but when running, it throws java.lang.NoClassDefFoundError: clout/core/CompiledRoute
. Looks like the clout is a library required by compojure. Is it matter to use compojure as router with graalvm? or just I missed something. What kind of libraries should I avoid when working with graalvm.
graalvm will try to only compile code that it thinks is necessary at runtime. there's a few different ways that graalvm might have decided it didn't need to include CompiledRoute: • classes not AOT'd • CompiledRoute not a direct or indirect dependency of the uberjar's main namespace. If you're already doing AOT, then I would check to see if you have a main namespace set for your uberjar and that your main namespace either directly requires/imports the CompiledRoute class or that CompiledRoute is required by a namespace that your main namespace depends on
What tooling you use for native-image build. Looks like my AOT only process files in my project, there's no classes generated for dependency libraries.
I've used both lein and clj
here's lein. notice the :profiles {:uberjar {:aot :all}}
(defproject terminal-todo-mvc "0.1.0-SNAPSHOT"
:description "FIXME: write description"
:url ""
:license {:name "EPL-2.0 OR GPL-2.0-or-later WITH Classpath-exception-2.0"
:url " "}
:dependencies [[org.clojure/clojure "1.10.2-alpha1"]
[com.phronemophobic/membrane "0.9.27.2-beta"]
[com.googlecode.lanterna/lanterna "3.1.1"]]
:jvm-opts ["-Dclojure.compiler.direct-linking=true"]
:main ^:skip-aot terminal-todo-mvc.core
:target-path "target/%s"
:profiles {:uberjar {:aot :all}})
https://github.com/phronmophobic/terminal-todo-mvc/blob/master/compile_native.shfor clj, I use depstar. here's an example alias:
:depstar-membrane
{:replace-deps {com.github.seancorfield/depstar {:mvn/version "2.0.216"}}
:ns-default hf.depstar
:aliases [:graal-compile]
:exec-fn hf.depstar/uberjar
:exec-args {:group-id "com.phronemophobic.mobiletest"
:artifact-id "membrane"
:version "1.00-beta-1"
:sync-pom true
:aot true
:compile-ns [;;avclj.main avclj.libavclj
com.phronemophobic.mobiletest.membrane
]
:main-class com.phronemophobic.mobiletest.membrane
:jar "target/mobiletest-uber.jar"
;;Disable tensor code generation and ensure direct linking.
:jvm-opts ["-Dtech.v3.datatype.graal-native=true"
"-Dclojure.compiler.direct-linking=true"
"-Dclojure.spec.skip-macros=true"]}}
then you just build the jar with: clojure -X:depstar-membrane
@U0NBGRGD6 please show your build, you need at least initialize-at-build-time
I found that I cannot access fields of deftype
instances in go blocks when building graalvm native-images (the same code works fine on the regular JVM). Where is a good place to report that? Clojure JIRA? Or to the graalvm folks?
I made a minimal repro, I can publish that to GitHub if helpful
a minimal repro would be helpful
it's also an example of building a native-image w/ tools.build in case that's interesting to anyone: https://github.com/cap10morgan/graalvm-deftype-field-bug
oh, let me throw a README on that real quick...
does (:a thing)
work?
Also, can you set (set! *warn-on-reflection* true)
and see if you need a type hint?
@cap10morgan I suspect you're prone to reflection here
yeah, seems like it. In the code where I first discovered it, it is type-hinted. I'll try that here too, though (and the keyword access).
README is pushed
huh, type hinting fixes it here, but not in the original code where it cropped up. :thinking_face:
yeah, and I've found that warn-on-reflection seems to complain about reflection at the beginning of go blocks (not the actual lines where it occurs) no matter how much type hinting I put in there
that's a good idea
looks like the reflection config fixed it (set allPublicFields
and allPublicMethods
to true
for my type)
going to see if there's a core.async bug to report though
oh, this is interesting. if I move the creation of the type instance into the go block (which I noticed was a difference between my actual code and the repro), it doesn't warn about reflection but it does blow up even w/ type hints. I'll push that change.
pushed
If you move the type creation into the go block, it seems like it wouldn't run at compile/build time. deftype creates a class, which can't be done at runtime.
not the deftype
, just the call to ->Thingy
ohhhh.
but then it worked when I built it again
I'm trying to repro the reflection warnings on the (go ...)
line behavior from my original code but no dice so far