Fork me on GitHub

@alexmiller hrm I'm realizing I looked at the AOT issue probably 4 years ago but gave up - in the assembly I tried to elide the namespaces, but I had commented it out


after fiddling w/ clojure-maven-plugin - I figured out how to elide AOTed classes for the deps


however it will not elide the deftype'd classes


I shrugged and changed the assembly, checked they are no longer in the jar


but when I try to use the AOTed ClojureScript I see this:


 "Execution error (ClassNotFoundException) at (\\n",
 {:clojure.error/class java.lang.ClassNotFoundException,
  :clojure.error/line 382,
  :clojure.error/source "",
  :clojure.error/phase :execution},
  [{:type clojure.lang.ExceptionInfo,
    :message "Unexpected error during REPL initialization",
    :data {:cljs.repl/error :init-failed},
    :at [cljs.repl$repl_STAR_ invokeStatic "repl.cljc" 1218]}
   {:type java.lang.NoClassDefFoundError,
    :message "clojure/tools/reader/reader_types/IndexingReader",
    :at [cljs.repl$repl_STAR_$fn__8140 invoke "repl.cljc" 1038]}
   {:type java.lang.ClassNotFoundException,
    :message "",
    [ findClass "" 382]}],
  [[ findClass "" 382]
   [java.lang.ClassLoader loadClass "" 424]
   [sun.misc.Launcher$AppClassLoader loadClass "" 349]
   [java.lang.ClassLoader loadClass "" 357]
   [cljs.repl$repl_STAR_$fn__8140 invoke "repl.cljc" 1038]
   [cljs.repl$repl_STAR_$fn__8172 invoke "repl.cljc" 1212]
   [cljs.compiler$with_core_cljs invokeStatic "compiler.cljc" 1477]
   [cljs.compiler$with_core_cljs invoke "compiler.cljc" 1466]
   [cljs.repl$repl_STAR_ invokeStatic "repl.cljc" 1166]
   [cljs.repl$repl_STAR_ invoke "repl.cljc" 1033]
   [cljs.cli$repl_opt invokeStatic "cli.clj" 325]
   [cljs.cli$repl_opt invoke "cli.clj" 312]


this defies my expectation a bit, because line 1038 in repl.cljc is just a function call


in anycase this hurdle would seem to block any approach (i.e. etc.) ?

Alex Miller (Clojure team)17:05:36

so the deftype classes are or are not in the output jar?


I altered the assembly to exclude them, if I include the deftypes it works

Alex Miller (Clojure team)17:05:01

so what's in the jar - just clojurescript, but compiled?


AOTed ClojureScript, changing the clojure-maven-plugin settings elides all AOTed fns from data.json, tools.reader, and transit-clj


however, it does not elide the backing interface to protocol, nor the deftypes

Alex Miller (Clojure team)17:05:20

yeah, this is kind of a rocky area wrt protocols


so it seems like AOTed ClojureScript just cannot get rid of the potential conflict w/o vendorizing tools.reader and causing a different kind of breakage


ok so unless you think different I don't think anything can be done about this problem same as 4 years ago


either you manage the deps carefully, or you use the slim JAR

Alex Miller (Clojure team)17:05:52

and what were the difficulties in vendorizing? knobs were exposed up through CLJS with the original names?


ClojureScript works as library / tooling foundation


if we vendorize tools.reader everybody has to know abou tthat

Alex Miller (Clojure team)17:05:45

they use those foundations directly in some cases?


because you can alter reading

Alex Miller (Clojure team)17:05:16

I'm trying to be specific enough to push on this, I just don't know this area enough


we don't really hide anything because we don't know how it's going to be used


you can bind the dyn vars for tools.reader


so anyone who doing custom analysis, or custom reading stuff and these other entrypoints - they would break

Alex Miller (Clojure team)17:05:18

so how big is that surface area? like bindings could be copied if we're talking just a few things like reader/*alias-map*

Alex Miller (Clojure team)17:05:22

there are like 4 dynamic vars in tools.reader

Alex Miller (Clojure team)17:05:31

(I understand this is all a big pain in the ass)

Alex Miller (Clojure team)17:05:52

just trying to understand the scope of the effort


I think the impact where you can bind outside is only cljs.analyzer and cljs.compiler


and it appears yes it's really only *alias-map* that can be configured

Alex Miller (Clojure team)17:05:51

data.json and transit-clj are both single namespace libs so should be relatively easy to vendor


yeah I'm not concerned about those at all


they are too deep / specific to be of interest / problem


only the reader knob is real issue

Alex Miller (Clojure team)17:05:49

I mean, seems like it would be pretty easy to bind to tools.reader/alias-map if it exists


like a pure dynamic look up since we don't want to pull that into AOT - ns-resolve


ok looks like vendorzing data.json, transit-clj worked - tools.reader going to be way more annoying


What's the annoying bit? (I have vendorized tools reader in clj-kondo for years now. )

Alex Miller (Clojure team)21:05:21

you're holding out on us man!

😆 2

What was the argument against AOT-ing at all?

Alex Miller (Clojure team)21:05:54

I don't think there is a reason not to AOT once you vendor

Alex Miller (Clojure team)21:05:52

I think the "don't want to pull that into AOT" above is re referencing tools.reader/alias-map


for tools reader I used to inline that dependency, it worked reasonably well, perhaps I had to change one or two things manually


I don't fully understand the problem around the dynamic var though, that is probably the real "pain"?


ah right, if you vendor tools reader, the dynamic var API surface changes

Alex Miller (Clojure team)22:05:02

and it's ok to look it up and re-bind, IF it exists (but not if it doesn't)