Skip to content

method code too large #135

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
hughjfchen opened this issue Jul 10, 2015 · 9 comments
Closed

method code too large #135

hughjfchen opened this issue Jul 10, 2015 · 9 comments

Comments

@hughjfchen
Copy link

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
Copy link
Member

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
Copy link
Author

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,

@hughjfchen
Copy link
Author

Thanks,Deraen.

@hughjfchen
Copy link
Author

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
Copy link

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
Copy link
Member

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
Copy link
Member

ikitommi commented Aug 9, 2015

can this be closed?

@hughjfchen
Copy link
Author

Yes,it could be closed.

psarando added a commit to cyverse-archive/DiscoveryEnvironmentBackend that referenced this issue Aug 27, 2015
Allow these projects to AOT compile all namespaces except for their route namespaces that use the compojure-api macros.
See metosin/compojure-api#135 (comment) and metosin/compojure-api#102 for why compojure-api macros should not be AOT compiled.
johnworth pushed a commit to cyverse-de/data-info that referenced this issue Aug 29, 2016
Allow these projects to AOT compile all namespaces except for their route namespaces that use the compojure-api macros.
See metosin/compojure-api#135 (comment) and metosin/compojure-api#102 for why compojure-api macros should not be AOT compiled.
johnworth pushed a commit to cyverse-de/iplant-groups that referenced this issue Aug 29, 2016
Allow these projects to AOT compile all namespaces except for their route namespaces that use the compojure-api macros.
See metosin/compojure-api#135 (comment) and metosin/compojure-api#102 for why compojure-api macros should not be AOT compiled.
johnworth pushed a commit to cyverse-de/metadata that referenced this issue Aug 29, 2016
Allow these projects to AOT compile all namespaces except for their route namespaces that use the compojure-api macros.
See metosin/compojure-api#135 (comment) and metosin/compojure-api#102 for why compojure-api macros should not be AOT compiled.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants