This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-11-24
Channels
- # announcements (11)
- # beginners (72)
- # calva (11)
- # cider (12)
- # clj-kondo (147)
- # clojure (6)
- # clojure-new-zealand (2)
- # clojuredesign-podcast (2)
- # clojurescript (36)
- # cursive (2)
- # datomic (5)
- # emacs (4)
- # fulcro (57)
- # graalvm (104)
- # graphql (2)
- # jobs (1)
- # joker (1)
- # kaocha (3)
- # malli (51)
- # off-topic (2)
- # portkey (1)
- # reagent (18)
- # shadow-cljs (26)
- # spacemacs (7)
- # tools-deps (5)
- # vim (4)
Hmm, graal 19.3.0 doesn't require bundling libsunec for crypto libs, but the warning is still triggered: > WARNING: The sunec native library, required by the SunEC provider, could not be loaded.
I wonder if the Java code that makes the check relies on checking if a dynamic library is loaded
might be that I'm doing something wrong in my hobby thing: https://github.com/viesti/ku
I'm using javax.crypto
package, despite the warning, the compiled image runs with 19.1.1
too, thought that the warning would go away in 19.3.0
ah, I don't know about that. you can also try the GraalVM slack in the native channel (or search the issues on Github)
They actually mention issue 951 in the release notes: https://www.graalvm.org/docs/release-notes/19_3/#native-image > Note that the sunec native library of SunEC provider gets statically linked into an image if required (see #951). Thus native images do not depend on the sunec shared library anymore at runtime.
no, I'm not using crypto explicitly, but things like (slurp "
`https://www.clojure.org``")` work now
@viesti for https I needed also this: https://github.com/borkdude/babashka/blob/87accff420dcf4cbe3cabe8f902c3560877fbdb1/script/compile#L39
right, wasn't paying attention to that since I wasn't using https, but crypto libs for another purpose
Yeah, I haven't tried what you are trying so mmv, but I can really recommend the GraalVM slack for these kinds of questions. Making a pure Java repro of your problem will probably be helpful for an issue
This is a pure Java repro of another issue: https://github.com/sogaiu/stdcpp-link-error
I think the 19.3.0 release is a super thing, should make graalvm use quite better if the crypto hassle is removed
was thinking that the github issues linking to this would be closed, but maybe they didn't yet have time to do so 🙂
What I'm curious about is that there seems to be quite many Java microframeworks which advertise Graal advantages (Quarkus, Micronaut, ...)
maybe even the crypto hassle hasn't been enough of an issue to not prevent these frameworks/libs from coming about
the crypto hassle could be solved if you set the sunec lib in a place that was on the java.library path
yup, I guess that's more manageable server side, for a desktop tool it was an additional step
Seems possible, although some issues: https://github.com/oracle/graal/issues/1867
I'm writing up a blog post and when people confirm some findings I'll help edit the github repo
just tried to run my hello world test app with Clojure 1.10.1 and GraalVM 19.3.0 app that uses clojure.test/run-tests
and it fails with unbalanced monitors
.
for completeness reran same hello world test app with Clojure 1.10.1 CLJ-1472 patched and it works.
for clj-kondo i did edit project.clj to point at clojure 1.10.1 -- odd that babashka already points there...wonder why that is
@sogaiu clj-kondo also supports 1.9.0, that's why that's the minimum version in project.clj. babashka doesn't have JVM usage, so there it doesn't matter
i previously needed it for https://github.com/lvh/cljurl-graalvm-demo and now I don't
just tried our spec-test from https://github.com/lread/clj-graal-docs/tree/master/CLJ-1472 and it fails with plain Clojure 1.10.1
yeah, some things trigger the locking issue others don't for example clojure.test/run-tests
seems to cause it but clojure.test/test-vars
does not.
https://www.lvh.io/posts/clojure-and-native-image-on-jdk-11-flavored-graalvm-1930%2B/ patches welcome: https://github.com/lvh/lvh.github.io/blob/source/posts/clojure-and-native-image-on-jdk-11-flavored-graalvm-1930%2B.md
but I'm a security guy at a company that HN pays attention to, I can't ship things with less-than-perfect TLS, so maybe I care a little bit more than everyone else :)
@lvh on a side note, it looks like you use taylorwood's lib -- do you not have issues with long classpaths on windows?
> With Graal 19.3.0, the error appears to have simply disappeared. considering the evidence above, that may not be true?
@lvh did you try compiling the exact same code with 19.2.1 and did you see the locking error in that case?
of course entirely possible that a stale classfile is actually causing the observation :)
locking problems that disappear sometimes are indication of race condition hell 😉
thanks for the graalvm discussion and help, I've started working on a small graalvm-built utility for turning data into tables at the cli: https://github.com/justone/tabl