still no sign of land, how long is it? 33 days, sir. errm, i guess a .tar.gz and .zip count as releasing? haven't found release notes yet though...

https://www.graalvm.org/docs/release-notes/19_3/

> With the major update to the 19.3 version, we announce the first release of GraalVM based on JDK 11

> GraalVM 19.3 switched to using the JDK native code instead of manual substitutions. For GraalVM Native Image this switch to Java Native Interface (JNI) platform enabled the possibility to provide support for JDK 11 and extended support for Windows OS. It has no impact on startup time or memory footprint, and eliminates the need for shipping JDK libraries such as libsunec.so along with native images that use Java crypto services. GraalVM now ships with statically linkable version of the JDK libraries. > > 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.

> a preview of GraalVM Community Edition on JDK 11 for ARM64 architecture. It includes the support for all JVM languages.

404 for https://github.com/oracle/graal/releases/download/vm-19.3.0/graalvm-ce-linux-amd64-19.3.0.tar.gz though

@sogaiu it seems to be here now? https://github.com/oracle/graal/releases

https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-19.3.0

thanks -- got the url wrong -- the pattern changed 🙂

yeah, it seems they just released it when I looked 🙂

he he i lose 🙂 btw, there are now java 8 and java 11 separate downloads i guess

> 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. Wow, that's great news for babashka

it seems like it would be beneficial at least for all things that use ssl?

yes

I'll try it out

does the arm64 thing mean there's a better chance of some of your stuff working on android?

I guess so? @sb was already trying this on ARM I think?

that would be great -- would love to be able to do some things on a tablet locally

maybe using sci there could be a CLJ repl on Android again

just for playing around

yes! have been waiting so many years for this

wasn't there one years ago?

there was also an issue posted at babashka: https://github.com/borkdude/babashka/issues/71 about Android. if anyone's interesting in maintaining that

i used to do clojure on android dev, yes, but various drawbacks

afaik, getting java to work with termux has not been successful

perhaps that has changed recently

but babashka can be compiled to native architecture. I don't know what it entails exactly to get this into termux, I'm unfamiliar with it

iirc, their packaging format is based on .deb

first attempt with Graal jvm 11 19.3.0:

Could not resolve java.lang.UNIXProcess for reflection configuration.

other issue with jdk 8 upgrade: https://github.com/borkdude/babashka/issues/121

If you use java 11 you get the same?

yes, I tried that first. the issue has already been found now (see #native-image on GraalVM slack)

it's an error in 19.3.0

https://github.com/oracle/graal/issues/1848

some more words on 19.3.0 release: https://medium.com/graalvm/graalvm-19-3-0-dfdb6f4ec8ed

@lee tnx for that

> GraalVM Native Image functionality now also supports Java 11 code as an early adopter technology feature so expect problems with java 11 stuff i guess 🙂

ah, the builds are now under a different repository's releases section

ya they moved: https://github.com/graalvm/graalvm-ce-builds/releases

upgrading to JVM 8 worked now, there is a problem when you have a reflection config for all methods of Thread ,since that also makes deprecated methods accessible and they try to link those

@sogaiu now that they seemed to have fixed static linking for Windows, maybe it's worth a try for clj-kondo again

indeed -- i am unexpectedly away from my windows dev env for much longer than expected. i will investigate what i can cobble together with what i've got at hand.

I'll try upgrading clj-kondo to 19.3.0 and see what appveyor makes of it

🤞

I feel like they buried the lede there, I’m on my way to Conj so I can’t check right now but it looks like they fixed https://github.com/oracle/graal/issues/1336

@lvh Yes, trying this out for babashka now (see #babashka)

It seems to work

Praise Graal!

@taylor ^ no more SSL trouble for clojurl as well when you upgrade to 19.3.0

Heya, unrelated to the 19.3.0 release, I've been looking at why my rewrite-cljc tests bloat native-image RAM usage (so much so I can't run them on circleci). I've been experimenting with hello world GraalVM apps. What I see is that clojure.test discovers what tests it will run at runtime using functions such as ns-interns. When I brought an ns-interns call into my hello world GraalVM app, it exhibited similar bloat and exe size to my hello world test GraalVM app. To avoid the bloat, I'm thinking a cljs test approach could work. If I understand, out of necessity, cljs builds up tests to run at compile time via macros.

By the way (might be old news to the more experienced, but), I find GraalVM's native-image expert option -H:+PrintAnalysisCallTree useful in figuring out what it being brought into a native image.

in 19.3.0, it looks like arguments to native-image that include = need to be wrapped in double quotes

e.g. it appears one must write something like:

"-H:Name=constdin" ^

-H:Name=constdin ^

@lee ^

I shall review clj-graal-docs, thanks for the tip @sogaiu.

borkdude encountered a (possibly) related issue with glob / wildcard (?) expansion -- a query has been made at the graalvm slack, so may be we'll have an answer on that before too long

it's a bit early to tell, but: https://github.com/oracle/graal/issues/1469 may have been addressed. have only tested briefly, but i'm not seeing the problems i saw before.

What OS did you find the double quote issue on @sogaiu?

we were both trying windows 10 i think

borkdude was using appveyor and i'm trying a vm

oh I see... so macOS and linux are likely ok?

haven't tried 🙂

I'll give it a go on macOS and linux

i think borkdude may have tried building babashka -- so he may know about macos

I didn't see problems with a non-Windows

what shell are you two using on Windows?

i used powershell, powershell core, windows command prompt and windows 7.1 sdk prompt (probably just command prompt with customizations)

i think the warning message is generated by native-image

so not a bash shell

definitely not 🙂

no matter how many quotes I add, the warning stays there

first i got the warning, and the build failed

ok, so I don't have anything to correct in clj-graal-docs yet as we are all bash-ful there currently.

then i added quotes, still got the warning, but the build succeeded

This happens on AppVeyor now:

C:\projects\clj-kondo>echo (inc 1)   | clj-kondo --lint - 
linting took 14ms, errors: 0, warnings: 0

This is the relevant artifact if anyone has Windows and wants to try it out: https://ci.appveyor.com/api/buildjobs/cvvynbmt0w2183o9/artifacts/clj-kondo-2019.11.08-SNAPSHOT-windows-amd64.zip

@lee perhaps you're right -- i don't have data for running on linux yet as i'm waiting on the arch linux package (the maintainer was making some queries at the graalvm slack)

fwiw, I have used the git bash shell on Windows https://gitforwindows.org/

that's what i've got too -- iiuc, at least the last i checked, native-image building won't work unless you use the windows 7.1 sdk prompt

this may have changed in recent times, but that was the case originally

ah, ok, I was using it for cljs work, not graal work...

i use it for "things-other-than-graal" 🙂

There is still something wrong with the resource configuration though:

C:\projects\clj-kondo>echo (inc)   | clj-kondo --lint - 
linting took 16ms, errors: 0, warnings: 0

This is probably not a new problem though

i'll do some digging about .*