Encore 2.58 dependency throws "Method too large" runtime exception

[theronic]

When adding [com.taoensso/encore "2.58.0"] dependency to to satisfy carmine's version complaints, boot repl throws the following runtime error:

java.lang.RuntimeException: Method code too large!, compiling:(ring/adapter/jetty.clj:20:1)
...
Caused by: java.lang.RuntimeException: Method code too large!
; and then later:
Caused by: java.lang.ClassNotFoundException: ring.adapter.jetty

If I take out encore, the exception goes away. Is this some conflict with another library?

Here is my list of dependencies in build.boot:

:dependencies '[[org.clojure/clojure "1.7.0"]
                  [org.clojure/tools.nrepl "0.2.12" :scope "test"]
                  [clojurewerkz/quartzite "2.0.0"]

                  ;; Testing
                  [adzerk/boot-test "1.1.1"  :scope "test"]
                  [metosin/boot-alt-test "0.1.0-SNAPSHOT" :scope "test"]

                  ;; Logging
                  [com.taoensso/timbre "4.3.1"] ; Stable
                  [com.fzakaria/slf4j-timbre "0.3.2"]
                  [org.slf4j/log4j-over-slf4j "1.7.14"]
                  [org.slf4j/jul-to-slf4j "1.7.14"]
                  [org.slf4j/jcl-over-slf4j "1.7.14"]

                  ;; Web
                  [compojure "1.5.1"]
                  [environ "1.0.2"]
                  [clj-http "2.1.0"]
                  [crypto-password "0.2.0"]
                  [hiccup "1.0.5"]

                  ;; Database
                  [postgresql "9.3-1102.jdbc41"]
                  [funcool/clojure.jdbc "0.9.0"]
                  [honeysql "0.6.3"]
                  [nilenso/honeysql-postgres "0.2.0"]
                  ;[com.taoensso/encore "2.58.0"] => method too large exc.
                  ;[com.taoensso/carmine "2.13.0"]

                  [migratus "0.8.16"]

                  ;; Time
                  [clj-time "0.11.0"]

                  [ring/ring-jetty-adapter "1.5.0"]
                  [ring/ring-headers "0.2.0"]               ; can las this
                  [ring/ring-defaults "0.2.0"]
                  [ring/ring-mock "0.3.0" :scope "test"]

                  ;; REPL
                  [com.cemerick/drawbridge "0.0.7"]         ; probably only want this in debug mode

                  ;; Dev
                  [ring-refresh "0.1.2"]
                  [ring/ring-devel "1.4.0" :exclusions [org.clojure/clojure]]
                  ;; Analytics
                  [tvachon/clj-mixpanel "0.0.3"]]

[theronic]

I did the lein deps :tree thing but could not resolve the conflict, if that was the cause. In the end I downgraded my encore dep to 2.52.1 and carmine to 2.10.0.

[ptaoussanis]

Hi there,

Doesn't sound like anything obviously related to Encore from what I can tell, sorry. Not much for me to go on here.

Have you tried eliminating other dependencies, checking the Jetty adapter for known issues, Googling the error message, etc.?

[theronic]

Hi @ptaoussanis, thanks for the reply. I'm not that experienced with Clojure. I was hoping you might spot a glaring conflict in my deps pertaining to the latest version of encore, because an older version of encore seems to work with these deps. You can close this issue until I find something more concrete.

I googled around first and messed with deps for about 30 minutes before opening an issue. The exception occurs because the JVM has a method size limit of 64KB and something is causing some method (maybe a macro in encore?) to balloon, perhaps related to a chunking in jetty. I skimmed over the encore source and couldn't see anything off the bat that would do that, but I don't know enough about encore to give a knowledgeable opinion, so yeah :/.

[ptaoussanis]

Yeah, unfortunately nothing obvious on Encore's end that'd be a candidate for this kind of error.

Since it's the Jetty adapter ns that's throwing, I'd maybe start debugging by checking the handler fn that you're passing to Jetty. Try provide a simple degenerate (fn [ring-req] {:status 200 :body "okay"})-style handler and see if that causes the issue to go away.

If it does, you'd need to start digging into your handler code to see if anything obvious might be creating an unusually large JVM method, etc. Might be something that uses Encore/Truss, a faulty macro that's expanding recursively, something with a name import clash that's causing unintended recursion, etc.

Would offer more if I could, but think it's going to need some digging on your end.

Last suggestion: please make sure you've run lein clean to eliminate the possibility of corrupt build artifacts.

Good luck!

[ptaoussanis]

Closing for now, please feel free to reopen if you've got follow-up info to report. Cheers :-)