method code too large

[hughjfchen]

When I tried to build a uberjar with the following repository:
https://github.com/hughjfchen/midadmin-platform

I got "method code too large" error. I had to remove some API routes before built the uberjar
successfully.

The problem can be reproduced with following steps:
1.clone the above repo
2.run "lein uberjar"
3.You will get the "method code too large" error.

[ikitommi]

Hi. In a JVM a single method can be 64kb (of bytecode). In Compojure (and by so, in compojure-api) the route-trees are in the end nested functions, so a large route-tree can generate a large (bytecode) method.

Solution is to split your routes with defroutes* into multiple route-trees.

[hughjfchen]

Hi,Tommi,
Thanks for your reply.I used the defapi macro to define my API routes. Could you give me more specific instructions about how to split my API routes with defroutes*?
Thanks,

[Deraen]

https://github.com/metosin/compojure-api/blob/master/examples/src/examples/pizza.clj#L53
https://github.com/metosin/compojure-api/blob/master/examples/src/examples/thingie.clj#L90

[hughjfchen]

Thanks,Deraen.

[hughjfchen]

Dears,
I still got the same error message after having split my route-tree with defroutes*. I think all split routes will be mounted under a big routes-tree and that caused the error. Any thoughts?

[psarando]

This appears related to aot compiling the routes for the uberjar, and I see that your project is setup to :aot :all for the uberjar: https://github.com/hughjfchen/midadmin-platform/blob/982774665238a93a5beeaa838d23b9e9564f8f1e/project.clj#L57

We also ran into this issue with our project, and it showed up when we started using a large model schema as the return for a lot of our routes.

Our project is not setup like the default compojure-api project template, since we run it as an uberjar and need a main function that can parse command-line options. So we had to setup our project to only aot compile the main core namespace (and a few other essential namespaces), but not the routes or defapi namespaces: https://github.com/iPlantCollaborativeOpenSource/DiscoveryEnvironmentBackend/blob/f448e4cc03d23d057bcdc1e852ab7459ea5ed560/services/metadactyl-clj/project.clj#L48-L59

Also, the main function has to require, at runtime, the namespace which contains our (defapi app... call, then eval that app and pass the result to run-jetty: https://github.com/iPlantCollaborativeOpenSource/DiscoveryEnvironmentBackend/blob/f448e4cc03d23d057bcdc1e852ab7459ea5ed560/services/metadactyl-clj/src/metadactyl/core.clj#L64-L79

I found this first suggested in this comment: #33 (comment)

As mentioned in #102 (comment), lein ring will usually only aot compile the main function and requires the routes at runtime for default compojure-api projects (also note from that issue, aot compiling the routes and schemas can cause other errors).

[ikitommi]

thanks Paul! I have to study more with AOT to understand what happens. With defroutes*, the routes are accessed over a Var, so they should have a separate compilation target. Something strange happens with AOT, seems to inline everything.

But as Paul said, AOT just the base minimum, similar case also here: #129 (comment)

... this should be in the README.

[ikitommi]

can this be closed?

[hughjfchen]

Yes,it could be closed.