This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-07
Channels
- # announcements (4)
- # babashka (20)
- # beginners (167)
- # calva (1)
- # cider (18)
- # circleci (10)
- # clara (45)
- # clojure (85)
- # clojure-argentina (1)
- # clojure-europe (3)
- # clojure-finland (3)
- # clojure-greece (2)
- # clojure-italy (9)
- # clojure-nl (30)
- # clojure-spec (32)
- # clojure-survey (39)
- # clojure-uk (72)
- # clojurescript (12)
- # core-async (4)
- # data-science (3)
- # emacs (10)
- # figwheel-main (9)
- # fulcro (44)
- # graalvm (3)
- # jobs (12)
- # jobs-discuss (6)
- # joker (3)
- # juxt (1)
- # leiningen (4)
- # off-topic (23)
- # planck (5)
- # re-frame (4)
- # reitit (2)
- # remote-jobs (1)
- # shadow-cljs (43)
- # spacemacs (8)
- # test-check (19)
- # tools-deps (21)
Done filling out the survey. I'm running CLJS tests with https://github.com/Olical/cljs-test-runner which was not there so I put it in other. But because it also uses doo I also marked that field.
After years of running our production apps with java clojure.main we have just, this week, switched to using java with AOT'd classes -- interesting to see a question about exactly that 🙂
@seancorfield whoa how did you convince @hiredman 
?
Neither of us are thrilled about this change. And we're using it purely as the very last stage when building an uberjar, just to get service start up times down, so rolling deploys go faster.
I've resisted even looking at AOT for start up times until after I added --compile to depstar 🙂
Before AOT, anything from 20 seconds to a minute and a half, depending on the service and what else the box is doing. After AOT, looks to be 5-10 seconds across the board. Still reviewing the improvement. And that's with New Relic's instrumentation agent doing its thing.
Deployment artifacts increased in size by about 50%. And we still have a few things that we run with java -cp ... clojure.main but are also now much faster to start because nearly all "our" code is AOT'd.
We'll see whether it impacts debugging etc.
oh this is great information, I need to update our depstar dep to the latest and try out the --compile flag, thanks @seancorfield!
I suddenly feel as if up is down and left is right ... 🙂
Where's my "side eye" emoji? 🙂 Yeah, like I said, neither of us are happy about making this change really. It makes the artifact build process a lot slower, and it makes the artifacts themselves a lot bigger, but it does have a worthwhile startup time improvement, as we've been working on streamlining that.
Yes, for almost all our services.
Well, New Relic shows that metric but I wouldn't say we actively "track" it...
27,300 classes loaded right now, 3,430 unloaded, according to New Relic, on our main API service.
That's on Adopt OpenJDK 11.0.5
(we still have a few processes on Adopt OpenJDK 8u232 but those are mixed legacy technology)
Feel free to DM for more details if you want 🙂
I wondered what this question meant exactly. Does it mean you have a :gen-class somewhere, build an uberjar and call it with java -jar for example?
too late for this perhaps, but for Q 22 would a column for "don't have an opinion" have made sense?
You can skip any question
@borkdude gen-class not necessary for clojure.main. Only a -main method
java ..... clojure.main -m some.namespace
(clojure.main is a java class, which is surprising because most classes are capitalized)
@borkdude Yes, we had to add (:gen-class) to twelve subprojects in our monorepo, and we added pom.xml (generated by clojure -Spom) as well, to trigger depstar's ability to create a manifest etc. /cc @U050ECB92
We have always run our production tasks with java -cp path/to/uber.jar clojure.main -m our.main.ns in the past (which still works with an AOT'd JAR).
We're switching to java -jar path/to/uber.jar for JARs that were AOT'd with a (:gen-class) shortly.