[JENKINS-37984] org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script

[jenkins-infra-bot]

Note from the Maintainers

There is partial fix for this for Declarative pipelines in pipeline-model-definition-plugin v1.4.0 and later, significantly improved in v1.8.4.  Due to the extent to which it change how pipelines are executed it is turned off by default.  It can be turned on by setting a JVM property (either on the command-line or in Jenkins script console): org.jenkinsci.plugins.pipeline.modeldefinition.parser.RuntimeASTTransformer.SCRIPT_SPLITTING_TRANSFORMATION=true  As noted, this still works best with a Jenkinsfile with pipeline directive as the only root item in the file. Since v1.8.2 this workaround reports an informative error for pipelines using `def` variables before the pipeline directive. Add a @​Field annotation to those declaration. This workaround generally does NOT work if the pipeline directive inside a shared library method. If this is a scenario you want, please come join the pipeline authoring SIG and we can discuss. Please give it a try and provide feedback.

Hi,

We are getting below error in Pipeline which has some 495 lines of groovy code. Initially we assumed that one of our methods has an issue but once we remove any 30-40 lines of Pipeline groovy, this issue is not coming.

Can you please suggest a quick workaround. It's a blocker for us.

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
General error during class generation: Method code too large!

java.lang.RuntimeException: Method code too large!
	at groovyjarjarasm.asm.MethodWriter.a(Unknown Source)
	at groovyjarjarasm.asm.ClassWriter.toByteArray(Unknown Source)
	at org.codehaus.groovy.control.CompilationUnit$16.call(CompilationUnit.java:815)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1053)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:591)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:569)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:546)
	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
	at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:67)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:410)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:373)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:213)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:410)

1 error

	at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1073)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:591)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:569)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:546)
	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
	at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:67)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:410)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:373)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:213)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:410)
Finished: FAILURE

---

Originally reported by anudeeplalam, imported from: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script

• status: Open
• priority: Blocker
• component(s): workflow-cps-plugin
• resolution: Unresolved
• votes: 89
• watchers: 111
• imported: 2025-12-07

Raw content of original issue

Note from the Maintainers

There is partial fix for this for Declarative pipelines in pipeline-model-definition-plugin v1.4.0 and later, significantly improved in v1.8.4.  Due to the extent to which it change how pipelines are executed it is turned off by default.  It can be turned on by setting a JVM property (either on the command-line or in Jenkins script console):

org.jenkinsci.plugins.pipeline.modeldefinition.parser.RuntimeASTTransformer.SCRIPT_SPLITTING_TRANSFORMATION=true 

As noted, this still works best with a Jenkinsfile with pipeline directive as the only root item in the file.
Since v1.8.2 this workaround reports an informative error for pipelines using `def` variables before the pipeline directive.  Add a @Field annotation to those declaration.
This workaround generally does NOT work if the pipeline directive inside a shared library method. If this is a scenario you want, please come join the pipeline authoring SIG and we can discuss. 

Please give it a try and provide feedback.  



Hi,

We are getting below error in Pipeline which has some 495 lines of groovy code. Initially we assumed that one of our methods has an issue but once we remove any 30-40 lines of Pipeline groovy, this issue is not coming.

Can you please suggest a quick workaround. It's a blocker for us.


org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
General error during class generation: Method code too large!

java.lang.RuntimeException: Method code too large!
	at groovyjarjarasm.asm.MethodWriter.a(Unknown Source)
	at groovyjarjarasm.asm.ClassWriter.toByteArray(Unknown Source)
	at org.codehaus.groovy.control.CompilationUnit$16.call(CompilationUnit.java:815)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1053)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:591)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:569)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:546)
	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
	at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:67)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:410)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:373)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:213)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:410)

1 error

	at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1073)
	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:591)
	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:569)
	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:546)
	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
	at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:67)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:410)
	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:373)
	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:213)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:410)
Finished: FAILURE

5 attachments

• JenkinsCodeTooLarge.groovy
• Script_Splitting.groovy
• Script_Splittingx10.groovy
• errorIncomaptiblewithlocalvar.txt
• java.png

  

[jenkins-infra-bot]

• Remote link associated with this issue:

  • PR-355

[jenkins-infra-bot]

pmcnab:

• Original comment link
• Raw content of original comment:

  I've run into the same problem.  I have a large (200+kb) pipeline script that is generated from our legacy build specification language.  
  
  My generated code is broken up into stages, with each stage running a potentially large parallel pipeline operation, where each platform of a given target is built.
  
  After some googling about the underlying cause, I attempted to break it up by having each stage be defined as a method and calling the method rather than just having all the code in one giant block, but it didn't help.  
  
  As this will impact a lot of people trying to migrate to the Jenkins pipeline, and may make them throw up their hands due to the error being vague and unhelpful (which I realize is not the fault of Jenkins, but the underlying Java/Groovy architecture), it might be good to have some specific guides on how to deal with this.
  
  

I've run into the same problem. I have a large (200+kb) pipeline script that is generated from our legacy build specification language.

My generated code is broken up into stages, with each stage running a potentially large parallel pipeline operation, where each platform of a given target is built.

After some googling about the underlying cause, I attempted to break it up by having each stage be defined as a method and calling the method rather than just having all the code in one giant block, but it didn't help.

As this will impact a lot of people trying to migrate to the Jenkins pipeline, and may make them throw up their hands due to the error being vague and unhelpful (which I realize is not the fault of Jenkins, but the underlying Java/Groovy architecture), it might be good to have some specific guides on how to deal with this.

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  Surprised that breaking it up into separate methods did not help. Other than that, I have no suggestions offhand.
  

Surprised that breaking it up into separate methods did not help. Other than that, I have no suggestions offhand.

[jenkins-infra-bot]

pmcnab:

• Original comment link
• Raw content of original comment:

  Yeah it's kind of puzzling – as part of my testing I had reduced the number of stages significantly.
  
  So a version that worked had 4 stages with no methods and it was about 1720 lines.
  
  With the full set of stages (27), the number of lines is about 5300 lines.  Breaking it up into methods had no method larger than about 450 lines, but it wouldn't run.  
  
  I also went in and removed the 4 stages that had worked, which put the entire script down to ~3600 lines broken out into methods, and that wouldn't run either.  
  

Yeah it's kind of puzzling – as part of my testing I had reduced the number of stages significantly.

So a version that worked had 4 stages with no methods and it was about 1720 lines.

With the full set of stages (27), the number of lines is about 5300 lines. Breaking it up into methods had no method larger than about 450 lines, but it wouldn't run.

I also went in and removed the 4 stages that had worked, which put the entire script down to ~3600 lines broken out into methods, and that wouldn't run either.

[jenkins-infra-bot]

pmcnab:

• Original comment link
• Raw content of original comment:

  Whoops.  Well cancel what I said.  When I generated the code with what I intended to be methods I was actually defining closures attached to a variable. When I did it properly as methods it's ok with it.
  
  So more specifically, for those of you who find this, what I used to have was:
  
  stage foo
  parallel([
   ... giant list of maps ...
  ])
  
  
  What I changed it to was:
  
  stage foo
  def build_foo() {
    parallel([
       ...giant list of maps...
    ])}
  build_foo()
  
  
  

Whoops. Well cancel what I said. When I generated the code with what I intended to be methods I was actually defining closures attached to a variable. When I did it properly as methods it's ok with it.

So more specifically, for those of you who find this, what I used to have was:

stage foo
parallel([
 ... giant list of maps ...
])

What I changed it to was:

stage foo
def build_foo() {
  parallel([
     ...giant list of maps...
  ])}
build_foo()

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  Sounds like a good candidate for a self-answer.
  

Sounds like a good candidate for a self-answer.

[jenkins-infra-bot]

pmcnab:

• Original comment link
• Raw content of original comment:

  I made one – I still think this case should be touched on in the Pipeline docs.  I don't think searching Jira or StackOverflow is a substitute for documentation
  

I made one – I still think this case should be touched on in the Pipeline docs. I don't think searching Jira or StackOverflow is a substitute for documentation

[jenkins-infra-bot]

jglick:

• Original comment link
• Raw content of original comment:

  Sure, that is why this is still open.
  

Sure, that is why this is still open.

[jenkins-infra-bot]

phillan:

• Original comment link
• Raw content of original comment:

  problem seems to be linked with the size all the script but I remarked it's linked also according number and size of stages.
  A workaround consists to declare a function called in some big stages.
  
  before :
  
  stage ('build') {
      ....
      if (.....) {
     } else {
     }
    .....
  }
  
  workaround 
  
  def build() {
      ....
      if (.....) {
     } else {
     }
    .....
  }
  stage ('build') {
     build()
  }
  
  

problem seems to be linked with the size all the script but I remarked it's linked also according number and size of stages.
A workaround consists to declare a function called in some big stages.

before :

stage ('build') {
....
if (.....) {
} else {
}
.....
}

workaround

def build() {
....
if (.....) {
} else {
}
.....
}
stage ('build') {
build()
}

[jenkins-infra-bot]

abayer:

• Original comment link
• Raw content of original comment:

  So this is happening because of how CPS transformation works - everything's getting wrapped in a single method behind the scenes, and that's ending up being too large. The best answer we've got is to move things out into shared libraries.
  

So this is happening because of how CPS transformation works - everything's getting wrapped in a single method behind the scenes, and that's ending up being too large. The best answer we've got is to move things out into shared libraries.

[jenkins-infra-bot]

llibicpep:

• Original comment link
• Raw content of original comment:

  Any workarounds? My scenario is quite specific, we threat Jenkinsfile as some sort of a JIT. No one working with it directly, it rather being generated automatically based on something else. It is essential for the debugging purposes to have a big picture perspective on how the resulting Jenkinsfile going to look like, and there is no benefits into splitting it or moving to the shared library (again this is not for humans and not made by humans).
  
  We need a way to increase this limit.
  

Any workarounds? My scenario is quite specific, we threat Jenkinsfile as some sort of a JIT. No one working with it directly, it rather being generated automatically based on something else. It is essential for the debugging purposes to have a big picture perspective on how the resulting Jenkinsfile going to look like, and there is no benefits into splitting it or moving to the shared library (again this is not for humans and not made by humans).

We need a way to increase this limit.

[jenkins-infra-bot]

ruudp:

• Original comment link
• Raw content of original comment:

  i use as "work a round" a script blok, for me it was a lot of work to change it but the result was smaller code witch is always good
  
     stages {
       stage('parallel stages') {
         steps {
           script {
  
  in my case i have 200-300 parallel  stages
  
  i generate the parallel stages with a single function and i execute more as 200-300 stages in parallel, this is very dynamic as this amount of stages depends on user input. So i use now script block to generate all the stages and execute the stages instead of using declarative Pipeline.
  
   
  

i use as "work a round" a script blok, for me it was a lot of work to change it but the result was smaller code witch is always good

   stages {
    stage('parallel stages') {
      steps {
        script {

in my case i have 200-300 parallel  stages

i generate the parallel stages with a single function and i execute more as 200-300 stages in parallel, this is very dynamic as this amount of stages depends on user input. So i use now script block to generate all the stages and execute the stages instead of using declarative Pipeline.

 

[jenkins-infra-bot]

llibicpep:

• Original comment link
• Raw content of original comment:

  The thing is I actually don't want to hide this code to the library. My library already does it's thing, I have a custom DSL syntax that my library goes through and generates resulting Jenkinsfile. And I follow TDD, so I got tests, and my tests basically checking the resulting Jenkinsfile vs given my own DSL. Hiding parts of Jenkinsfile into the library going to ruin the whole idea of testing for my project. Again the Jenkinsfile for me is kind of JIT, it's not a code to being read or created by human.
  

The thing is I actually don't want to hide this code to the library. My library already does it's thing, I have a custom DSL syntax that my library goes through and generates resulting Jenkinsfile. And I follow TDD, so I got tests, and my tests basically checking the resulting Jenkinsfile vs given my own DSL. Hiding parts of Jenkinsfile into the library going to ruin the whole idea of testing for my project. Again the Jenkinsfile for me is kind of JIT, it's not a code to being read or created by human.

[jenkins-infra-bot]

thelamer:

• Original comment link
• Raw content of original comment:

  I am running into this, example file: 
  
  https://pastebin.com/raw/fnKnYiMq
  
  If I rip out some env declaration blocks like: 
  
           script{
             env.CI_IMAGE = env.DEV_DOCKERHUB_IMAGE
             env.CI_TAGS = env.EXT_RELEASE + '-pkg-' + env.PACKAGE_TAG + '-dev-' + env.COMMIT_SHA
             env.CI_META_TAG = env.EXT_RELEASE + '-pkg-' + env.PACKAGE_TAG + '-dev-' + env.COMMIT_SHA
           }
  
  
  It will compile up and run, I already tried to move every script section out to functions, but still get Method to Large. 
   
  This is only ~800 lines and even if you compiled this text 10x over it would not be at the 64k java limit. 
  I am trying to understand how the workflow is interpreted that could result in this limit being hit.  
  

I am running into this, example file: 

https://pastebin.com/raw/fnKnYiMq

If I rip out some env declaration blocks like: 

 script{
   env.CI_IMAGE = env.DEV_DOCKERHUB_IMAGE
   env.CI_TAGS = env.EXT_RELEASE + '-pkg-' + env.PACKAGE_TAG + '-dev-' + env.COMMIT_SHA
   env.CI_META_TAG = env.EXT_RELEASE + '-pkg-' + env.PACKAGE_TAG + '-dev-' + env.COMMIT_SHA
 }

It will compile up and run, I already tried to move every script section out to functions, but still get Method to Large. 

 

This is only ~800 lines and even if you compiled this text 10x over it would not be at the 64k java limit. 

I am trying to understand how the workflow is interpreted that could result in this limit being hit.  

[jenkins-infra-bot]

slavik334:

• Original comment link
• Raw content of original comment:

  +1
  
  it is a real headache
  
  about 800-900 lines of code
  
  could you please enforce fixing this issue?
  

+1

it is a real headache

about 800-900 lines of code

could you please enforce fixing this issue?