Fork me on GitHub
#graalvm
<
2019-11-24
>
viesti16:11:58

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.

viesti16:11:46

I wonder if the Java code that makes the check relies on checking if a dynamic library is loaded

borkdude16:11:37

@viesti Not the case with babashka. Are you sure you are using the newest GraalVM?

viesti16:11:35

might be that I'm doing something wrong in my hobby thing: https://github.com/viesti/ku

viesti16:11:02

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

borkdude16:11:50

ah, I don't know about that. you can also try the GraalVM slack in the native channel (or search the issues on Github)

viesti16:11:05

does babashka use crypto jdk libs directly?

viesti16:11:25

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.

borkdude16:11:53

no, I'm not using crypto explicitly, but things like (slurp "`https://www.clojure.org``")` work now

viesti16:11:09

Interesting

viesti16:11:39

my stuff worked even before 😅

viesti16:11:09

if the url is passed at runtime, maybe a different check kicks in?

viesti16:11:19

right, wasn't paying attention to that since I wasn't using https, but crypto libs for another purpose

borkdude16:11:12

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

borkdude16:11:38

This is a pure Java repro of another issue: https://github.com/sogaiu/stdcpp-link-error

borkdude16:11:40

to give you an idea

viesti16:11:50

nice, thanks for the pointers, still have some room on my slack sidepanel 🙂

viesti16:11:37

seems that adding -H:EnableURLProtocols=http,https makes the warning go away

viesti16:11:48

I think the 19.3.0 release is a super thing, should make graalvm use quite better if the crypto hassle is removed

viesti16:11:24

was thinking that the github issues linking to this would be closed, but maybe they didn't yet have time to do so 🙂

borkdude16:11:26

Windows compilation also got better

viesti16:11:47

ah that too, haven't followed that much windows things

borkdude16:11:57

yeah, clj-kondo now works in Windows

viesti16:11:08

that is definately neat :)

viesti16:11:53

What I'm curious about is that there seems to be quite many Java microframeworks which advertise Graal advantages (Quarkus, Micronaut, ...)

viesti16:11:02

maybe even the crypto hassle hasn't been enough of an issue to not prevent these frameworks/libs from coming about

borkdude16:11:55

the crypto hassle could be solved if you set the sunec lib in a place that was on the java.library path

borkdude16:11:20

I had docs for this in babashka

borkdude16:11:25

(but now obsolete)

viesti16:11:59

yup, I guess that's more manageable server side, for a desktop tool it was an additional step

viesti16:11:59

I've forgotten that I used to package java apps for windows with NSIS installer 😅

viesti16:11:46

there used to be this multi-platform packager for JavaFX even, that created installer

viesti16:11:02

I guess JavaFX is possible via Graal now even

borkdude16:11:17

I saw tweets about this. It may require JDK11?

borkdude16:11:30

which they now support

viesti17:11:14

Yeah, I think I saw some tweets too

viesti17:11:25

Seems possible, although some issues: https://github.com/oracle/graal/issues/1867

viesti17:11:14

so cljfx could have graal binary

borkdude17:11:24

I can live without colors for now 😉

lvh18:11:27

FWIW it appears I can just use Clojure 1.10.1 now

lvh18:11:33

without the locking patch

sogaiu18:11:56

^ @lee @borkdude oh wow, that sounds great

lvh18:11:37

I'm writing up a blog post and when people confirm some findings I'll help edit the github repo

👍 4
lread18:11:58

I still seem to need the locking patch with 19.3.0

lread18:11:17

but maybe the need is reduced?

sogaiu18:11:12

making an attempt here

sogaiu18:11:36

first attempt seemed successful, will try with -Sforce

sogaiu18:11:56

doing one test with taylorwood's native-image tool and one with clj-kondo

sogaiu18:11:08

test with -Sforce appeared successful

lread18:11:30

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.

sogaiu18:11:04

so may be as you say the need is reduced

sogaiu18:11:18

i checked the classpath used here and it does contain clojure 1.10.1

lread18:11:26

I'm guessing that is the case.

sogaiu18:11:55

clj-kondo appears to have compiled here too

lread18:11:50

for completeness reran same hello world test app with Clojure 1.10.1 CLJ-1472 patched and it works.

👍 4
sogaiu18:11:03

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

sogaiu19:11:34

will try with jet

borkdude19:11:34

@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

borkdude19:11:58

clj-kondo is compiled with clojure 1.10.1 though, see script/compile

borkdude19:11:08

but it never hit the locking issue anywhere

sogaiu19:11:09

yes, i see the with-profile

sogaiu19:11:20

ah, that explains it i guess

sogaiu19:11:52

using pprint caused issues before right?

borkdude19:11:34

try clojure spec if you want to be sure.

borkdude19:11:55

(see Testing)

sogaiu19:11:28

pprint was enough, i got the unbalanced monitors thing

lread19:11:33

so the situation may be improved in some scenarios?

sogaiu19:11:52

i guess we'll have to see what lvh's post contains 🙂

lread19:11:01

looking forward to learning more @lvh!

👍 4
lvh19:11:36

i previously needed it for https://github.com/lvh/cljurl-graalvm-demo and now I don't

lvh19:11:42

(the locking patch)

lread19:11:04

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

lvh19:11:12

i added (println (clojure-version)) to confirm it's actually 1.10.1

lvh19:11:32

so maybe I just casually avoid using the spec library?

borkdude19:11:45

@lvh yes, you don't run into it necessarily

lvh19:11:18

FWIW with that app but just switching out GRAALVM_HOME I hit it

lread19:11:26

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.

lvh19:11:38

honestly I'm just over the moon they fixed TLS

lvh19:11:39

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 :)

sogaiu19:11:25

@lvh on a side note, it looks like you use taylorwood's lib -- do you not have issues with long classpaths on windows?

borkdude19:11:25

> With Graal 19.3.0, the error appears to have simply disappeared. considering the evidence above, that may not be true?

sogaiu19:11:51

there is a "FWIW" below, fwiw 😉

lread19:11:18

and the title "locking errors appear to be gone... sometimes?"

borkdude19:11:45

@lvh did you try compiling the exact same code with 19.2.1 and did you see the locking error in that case?

lvh19:11:55

cloudflare might be showing you an old version

lvh19:11:24

yep, the two versions are graalvm-ce-19.2.1, graalvm-ce-java11-19.3.0

lvh19:11:43

of course entirely possible that a stale classfile is actually causing the observation :)

borkdude19:11:44

and what about graalvm-ce-java8-19.3.0?

lvh19:11:41

hang on, I'm producing something a little more lab-grade to test properly

lvh19:11:17

this is easier with deps.edn since I have to override a dep

kulminaator20:11:23

locking problems that disappear sometimes are indication of race condition hell 😉

nate21:11:37

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

nate21:11:53

very very new

borkdude22:11:01

cool 🙂 feel free to add the link to the docs repo in the external resources

👍 4