GithubHelp home page GithubHelp logo

clj-easy / graalvm-clojure Goto Github PK

View Code? Open in Web Editor NEW
488.0 488.0 43.0 159 KB

This project contains a set of "hello world" projects to verify which Clojure libraries do actually compile and produce native images under GraalVM.

License: Apache License 2.0

Shell 4.95% Clojure 91.80% Makefile 0.48% Batchfile 0.55% Dockerfile 2.22%

graalvm-clojure's People

Contributors

agilecreativity avatar alekcz avatar avelino avatar brandonstubbs avatar brunobonacci avatar bsless avatar cnuernber avatar danielcompton avatar fierycod avatar genmeblog avatar jamartin9 avatar jeroenvandijk avatar jimpil avatar jrwdunham avatar k13gomez avatar lsh-0 avatar mohammedamarnah avatar mourjo avatar oakmac avatar phronmophobic avatar port19x avatar quoll avatar rdipardo avatar rorokimdim avatar ruedigergad avatar salvatoretosti avatar sveri avatar the-alchemist avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

graalvm-clojure's Issues

Problem running the aws-api-s3

I am getting the following errors:

./aws-api-s3 
Exception in thread "main" clojure.lang.ExceptionInfo: Cannot find resource cognitect/aws/s3/service.edn. {}
	at cognitect.aws.service$service_description.invokeStatic(service.clj:31)
	at cognitect.aws.service$service_description.invoke(service.clj:28)
	at cognitect.aws.client.api$client.invokeStatic(api.clj:67)
	at cognitect.aws.client.api$client.invoke(api.clj:22)
	at simple.main$_main.invokeStatic(main.clj:8)
	at simple.main$_main.invoke(main.clj:7)
	at clojure.lang.AFn.applyToHelper(AFn.java:152)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at simple.main.main(Unknown Source)

Not sure if anyone have idea about how to make this work.
I am guessing that it may have something to do with adding the following config as part of native-image generation.

My env:

graalvm-ce-java11-20.3.0
Clojure 1.10.1-rc2
Java 1.11.0

Make ring-jetty work

On master:

$ native-image --version
GraalVM Version 19.2.1 CE
$ java -version
openjdk version "1.8.0_232"
OpenJDK Runtime Environment (build 1.8.0_232-20191009173705.graal.jdk8u-src-tar-gz-b07)
OpenJDK 64-Bit GraalVM CE 19.2.1 (build 25.232-b07-jvmci-19.2-b03, mixed mode)
$ lein do clean, uberjar, native, run-native
Compiling simple.main
2019-10-24 14:38:17.909:INFO::main: Logging initialized @1477ms to org.eclipse.jetty.util.log.StdErrLog
Created /Users/danielcompton/Developer/clojure/test/graalvm-clojure/ring-jetty/target/ring-jetty-0.1.0-SNAPSHOT.jar
Created /Users/danielcompton/Developer/clojure/test/graalvm-clojure/ring-jetty/target/simple-main.jar
[./target/ring-jetty:62615]    classlist:   2,375.62 ms
[./target/ring-jetty:62615]        (cap):   1,128.28 ms
[./target/ring-jetty:62615]        setup:   2,440.11 ms
2019-10-24 14:38:26.546:INFO::ForkJoinPool-2-worker-12: Logging initialized @5707ms to org.eclipse.jetty.util.log.StdErrLog
[./target/ring-jetty:62615]   (typeflow):   5,140.84 ms
[./target/ring-jetty:62615]    (objects):   4,779.68 ms
[./target/ring-jetty:62615]   (features):     208.57 ms
[./target/ring-jetty:62615]     analysis:  10,351.47 ms
[./target/ring-jetty:62615]     (clinit):     206.89 ms
[./target/ring-jetty:62615]     universe:     503.52 ms
[./target/ring-jetty:62615]      (parse):     434.64 ms
[./target/ring-jetty:62615]     (inline):   1,418.28 ms
[./target/ring-jetty:62615]    (compile):   4,724.07 ms
[./target/ring-jetty:62615]      compile:   7,120.33 ms
[./target/ring-jetty:62615]        image:     850.46 ms
[./target/ring-jetty:62615]        write:     279.14 ms
[./target/ring-jetty:62615]      [total]:  24,094.02 ms
server started on: http://localhost:3000/
Exception in thread "main" java.lang.ClassNotFoundException: org.eclipse.jetty.server.ServerConnector
	at com.oracle.svm.core.hub.ClassForNameSupport.forName(ClassForNameSupport.java:60)
	at java.lang.Class.forName(DynamicHub.java:1174)
	at clojure.lang.RT.classForName(RT.java:2207)
	at clojure.lang.RT.classForName(RT.java:2216)
	at ring.adapter.jetty$server_connector.invokeStatic(jetty.clj:44)
	at ring.adapter.jetty$server_connector.doInvoke(jetty.clj:44)
	at clojure.lang.RestFn.invoke(RestFn.java:423)
	at ring.adapter.jetty$http_connector.invokeStatic(jetty.clj:57)
	at ring.adapter.jetty$http_connector.invoke(jetty.clj:55)
	at ring.adapter.jetty$create_server.invokeStatic(jetty.clj:122)
	at ring.adapter.jetty$create_server.invoke(jetty.clj:119)
	at ring.adapter.jetty$run_jetty.invokeStatic(jetty.clj:164)
	at ring.adapter.jetty$run_jetty.invoke(jetty.clj:127)
	at simple.main$_main.invokeStatic(main.clj:15)
	at simple.main$_main.invoke(main.clj:13)
	at clojure.lang.AFn.applyToHelper(AFn.java:152)
	at clojure.lang.AFn.applyTo(AFn.java:144)
	at simple.main.main(Unknown Source)

After applying ring-clojure/ring#381 locally, I was able to run this. Once that is merged, we should update the dependencies and I think ring-jetty will run.

asami

I just tried out asami locally:

https://github.com/threatgrid/asami

$ ./asami
(["Explorers"] ["Demolition Man"] ["Johnny Mnemonic"] ["Toy Story"])

Worked great, memory consumption during compilation is far more reasonable than datascript.
Hopefully once it gets durable storage it keeps working well like this.

Update README

Please update Readme to indicate the final size of the executable, including the sizes of all dependencies.

If one were to create a demo using this tool, how much does the end-user need to download and install assuming no dependencies are pre-installed.

Workaround for dynamic Var holding a SecureRandom instance

Hi there,

First of all many thanks for this repo - it contains some super valuable information! I just wanted to say that I was recently trying to create a native-image for cryptohash-clj, and it turns out that the problem was statically initialised instances of SecureRandom. You see, the library has a dynamic Var initialised with an instance of SecureRandom, and no matter what I did, I wasn't able to generate a working image (I tried literally everything). I wrapped that instance in a delay (see here), and now the native-image is working as expected.

I just thought you (or someone else) might find that information useful.

Kind regards

hickory and other jsoup dependents are incompatible

Idk where else to document this in a public manner.
Hickory, as well as most other projects labeling themselves as html parsers don't play nicely with graalvm.
This is because jsoup wants to be initialized at runtime and clojure libs at build time.
The project where I tried for days to get it to play with graal: bbyt

drewr/postal

I've been experimenting with drewr/postal to be able to send e-mails from a native-image.
So far it fails for me with:

#error {
 :cause "smtps"
 :via
 [{:type javax.mail.NoSuchProviderException
   :message "smtps"
   :at [javax.mail.Session getService "Session.java" 811]}]

I've tried adding com.sun.mail.smtp.SMTPTransport to the reflection config, but this didn't help.

Deprecation warning for `--initialize-at-build-time`

--initialize-at-build-time without arguments has been deprecated when not using --diagnostics-mode. With GraalVM 22.0.0 --initialize-at-build-time will only work with --diagnostics-mode for debugging purposes.
The reason for deprecation is that --initalize-at-build-time does not compose, i.e., a single library can make assumptions that the whole classpath can be safely initialized at build time; that assumption is often incorrect.

[http-kit] class initialization changes as of 2.5.2

Hello,
Following a bug fix in http-kit, to compile the client with version 2.5.2 the following initialization flag is required:

--initialize-at-run-time=org.httpkit.client.ClientSslEngineFactory\$SSLHolder

Will PR this soon

Cheers :)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.