This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-10-27
Channels
- # announcements (10)
- # beginners (95)
- # biff (2)
- # calva (33)
- # cherry (1)
- # clj-kondo (16)
- # clojure (96)
- # clojure-australia (1)
- # clojure-china (1)
- # clojure-europe (42)
- # clojure-filipino (1)
- # clojure-france (2)
- # clojure-hk (1)
- # clojure-indonesia (1)
- # clojure-japan (1)
- # clojure-korea (1)
- # clojure-my (1)
- # clojure-nl (1)
- # clojure-norway (24)
- # clojure-sg (11)
- # clojure-taiwan (1)
- # clojure-uk (1)
- # clojurescript (21)
- # cursive (22)
- # data-science (3)
- # events (7)
- # fulcro (3)
- # graalvm (4)
- # gratitude (6)
- # helix (11)
- # honeysql (7)
- # hoplon (1)
- # introduce-yourself (1)
- # jobs (2)
- # jobs-discuss (16)
- # lsp (15)
- # malli (14)
- # nbb (73)
- # practicalli (3)
- # reagent (8)
- # reitit (5)
- # releases (1)
- # ring (5)
- # rum (3)
- # sci (17)
- # scittle (7)
- # shadow-cljs (22)
- # tools-deps (26)
- # xtdb (9)
The uberjar output by b/uber
is much bigger than the one created by leiningen. is there any way to determine the source of the difference? (If this is something to ask in #C0AB48493 I can move the question over as well.)
Was your uberjar AOT'd with Leiningen? Perhaps that's the difference? Either way, I'll be interested to hear what comparing the contents of the two JARs reveals...
it was, we have :aot :all
in the :uberjar
profile.
Thanks for the suggestion, I'm looking now with zipinfo and seeing that 1) all of the dependency source files are included (.clj, .java) and 2) certain dependencies are included as well. makes me wonder how leiningen did it. For example, we use fundingcircle/jackdaw, which has a dependency on aleph. the tools uberjar has aleph/flow.clj etc and both aleph/utils/RequestTimeoutException.java and compiled aleph/utils/RequestTimeoutException.class files, whereas the leiningen doesn't have any files related to aleph in it.
How does jackdaw declare the dependency on aleph? I wonder if it assumes a Maven scope that tools.build/t.d.a don't understand?
Hmm, nope, it's a regular dependency... I would expect Leiningen to just add all that in...
It makes no sense for it to be excluded from an uberjar if it is a dependency. An uberjar needs everything so it can be run.
Perhaps there's something in your project.clj
that is telling Leiningen to exclude some of that stuff from the uberjar for some reason?
and it is possible to do the same by creating a modified basis that excludes a dep in tools.build if you want that. not sure why dependency sources would be included unless you're doing something to pull the source classifier jar
leiningen would traditionally make two jars. are you sure you are comparing the uberjar from lein to the uberjar from tools.build?
I made a new lein project, added aleph to it and ran lein uberjar
❯ ls -l target/uberjar
total 18032
drwxr-xr-x 4 dan wheel 128 Oct 27 12:09 classes
-rw-r--r-- 1 dan wheel 8501590 Oct 27 12:09 hi-0.1.0-SNAPSHOT-standalone.jar
-rw-r--r-- 1 dan wheel 13802 Oct 27 12:09 hi-0.1.0-SNAPSHOT.jar
drwxr-xr-x 3 dan wheel 96 Oct 27 12:09 stale
note there are two jars of vastly different sizesNow I'm curious how much difference in size there is (or not) between the actual uberjar from Leiningen (not the library JAR!) and the uberjar from tools.build
??
Using zipcmp
:
$ zipcmp -i muncher-0.1.0-SNAPSHOT-standalone.jar muncher-standalone.jar
--- muncher-0.1.0-SNAPSHOT-standalone.jar
+++ muncher-standalone.jar
...
- 1450 faa8953c buddy/core/bytes$concat$iter__63004__63010$fn__63011$iter__63006__63012$fn__63013$fn__63014.class
- 2704 dda4f5d4 buddy/core/bytes$concat$iter__63004__63010$fn__63011$iter__63006__63012$fn__63013.class
- 841 485e6fe9 buddy/core/bytes$concat$iter__63004__63010$fn__63011$iter__63006__63012.class
- 1882 6785282a buddy/core/bytes$concat$iter__63004__63010$fn__63011.class
- 783 ac02f762 buddy/core/bytes$concat$iter__63004__63010.class
+ 1450 3ed59749 buddy/core/bytes$concat$iter__63071__63077$fn__63078$iter__63073__63079$fn__63080$fn__63081.class
+ 2704 00c515eb buddy/core/bytes$concat$iter__63071__63077$fn__63078$iter__63073__63079$fn__63080.class
+ 841 e78f36c7 buddy/core/bytes$concat$iter__63071__63077$fn__63078$iter__63073__63079.class
+ 1882 fd25a2e6 buddy/core/bytes$concat$iter__63071__63077$fn__63078.class
+ 783 97cf0ea9 buddy/core/bytes$concat$iter__63071__63077.class
+ 984 954a77bf buddy/core/bytes$concat.class
- 984 a46bbf08 buddy/core/bytes$concat.class
- 2067 2450f6ba buddy/core/bytes$equals_QMARK_.class
+ 2067 621de668 buddy/core/bytes$equals_QMARK_.class
- 3564 6024f654 buddy/core/bytes$fill_BANG_.class
+ 3564 d744d4cf buddy/core/bytes$fill_BANG_.class
- 1758 dc20a963 buddy/core/bytes$fn__62989.class
+ 1758 00eb8eeb buddy/core/bytes$fn__63056.class
- 2292 98b7ccfc buddy/core/bytes$loading__6789__auto____62987.class
+ 2292 ecfbc801 buddy/core/bytes$loading__6789__auto____63054.class
+ 6129 7c316f0d buddy/core/bytes__init.class
- 6129 ec4dd1d6 buddy/core/bytes__init.class
what about the size difference? that’s comparing things you wouldn’t expect to be identical. But if that’s the diff (and its just counters in the compiler) you are golden
Looks like the sizes are all identical there.
the output .class files look to be the (roughly) same, maybe a byte of difference in the occasional file
(Clojure compilation is not a reproducible process, i.e., you don't get identical byte code each time you compile the same code but you get equivalent byte code -- those differences in generated classes are just that)
$ exa -la
.rw-rw-r-- 160M noah 27 Oct 11:24 muncher-0.1.0-SNAPSHOT-standalone.jar
.rw-rw-r-- 31M noah 27 Oct 11:23 muncher-0.1.0-SNAPSHOT.jar
.rw-rw-r-- 159M noah 27 Oct 11:21 muncher-standalone.jar
And I thought some of our uberjar files were big! 🙂
We don't do any splitting at all, so this is our entire 63k lines of clojure backend lol
(our largest one is about 79M at this point -- but we've been working hard to keep them small... most of ours are around 35M... about 18 uber JARs from 130K lines of Clojure)
