Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2020-09-30

Channels

#graalvm
<
2020-09-30
>
borkdude14:09:40

Anyone got postal working with graalvm?

borkdude14:09:07

$ rlwrap ./bb
Babashka v0.2.2-SNAPSHOT REPL.
Use :repl/quit or :repl/exit to quit the REPL.
Clojure rocks, Bash reaches.

user=> (require '[postal.core :as p])
nil
user=> (p/send-message {} {:from "" :to "" :body "hello"})
java.lang.NoClassDefFoundError [at <repl>:2:1]
I've already added [javax.activation/javax.activation-api "1.2.0"] but maybe I need some reflection config

alekcz14:09:06

@U04V15CAJ @U0FT7SRLP it's not working. I ended up have the core engine on JVM and the developer tool with Graalvm

alekcz14:09:32

I did try. But ended in java mail and that was a nope.

👍 3
alekcz14:09:14

But that was shared ago. I knew next to nothing about Graalvm then

borkdude14:09:14

I'm getting: 

javax.activation.UnsupportedDataTypeException: no object DCH for MIME type text/plain; charset=utf-8 [at <repl>:2:1]

borkdude14:09:22

I have added: 

'-H:IncludeResources=.*mailcap\.default*'
 '-H:IncludeResources=.*mimetypes\.default.*'
but it doesn't seem to help

borkdude14:09:15

oh a typo maybe

borkdude14:09:06

btw I haven't seen these resources been logged for a while with 

"-H:Log=registerResource:"

borkdude15:09:00

Maybe this Quarkus extension could be wrapped in some Clojure code: https://github.com/quarkusio/quarkus/tree/master/extensions/mailer But that wouldn't be the same as postal

borkdude15:09:30

ok, I'll leave it at this for now, summary in https://github.com/borkdude/babashka/issues/599

sergey22:09:08

does the -Dclojure.compiler.direct-linking=true actually do anything with GraalVM 20.2.0? I've not noticed any difference in my own projects

sergey22:09:44

Also tried compiling babashka with & without it and the compilation time was faster when I removed it

sergey23:09:05

When I say "removed it" I mean I removed it in both project.clj and the -J-D flag in the call to native-image that compiles the binary

borkdude07:10:45

It should have benefit on binary size and runtime speed at least, but in some cases also memory consumption during compilation

sergey17:10:54

Gotcha. I double checked with a (medium-sized) cli app at my company and didn't notice a significant difference except for maybe a 1-2% runtime speed improvement. I also tried recompiling babashka: the compilation w/out flags used a bit less RAM, and the non-flag binary was 1.5MB smaller (69.MB vs 70.8MB). Not sure if there's a performance difference between the two babashka builds

sergey17:10:57

Maybe there's a difference in very high-performance scenarios?

sergey18:10:13

I've seen the epiccastle post, but wasn't aware of that issue

borkdude18:10:06

it's not graalvm related per se, just performance related in general

borkdude18:10:11

the sci issue