Groovy Error: Unable to resolve class internal.GlobalVariable


I am facing the same error in Katalon_Studio_Windows_64-5.8.5.

unable to resolve class internal.GlobalVariable04:20:53  @ line 14, column 1.04:20:53    import internal.GlobalVariable as GlobalVariable04:20:53    ^

does anybody read the previous posts and attempting to apply the proposed workaround/fixes?
or this post is just about complaining and just waiting for the god’s to fix the issues?

by this way, the development team will never figure out what is the actual problem … so, yeah. keep up the good work.
good job you do, dear katalon users …

1 Like

It seems that the latest 5.9.1 has the fix for this issue based on release notes. I tried upgrading my version from 5.8.0 to 5.9.1 on OS : MacOS High Sierra 10.13.6 but Upgrade failed with below error

Unable to download update file from Katalon server

manoj said:

It seems that the latest 5.9.1 has the fix for this issue based on release notes. I tried upgrading my version from 5.8.0 to 5.9.1 on OS : MacOS High Sierra 10.13.6 but Upgrade failed with below error

Unable to download update file from Katalon server

We’ve fixed this issue. Somehow this file is not stored on the server when we upload it, so we’ve re-uploaded it to correct this issue.

Thanks for your report.


1 Like


I meet the same issue in Katalon 5.10.0. First of all, when I’m running test suites inside Katalon Studio, everything is fine. But when running in console mode, it throws error:

Groovy:unable to resolve class internal.GlobalVariable

However, it’s still able to run the tests. But when coming back to Katalon Studio, I’m not able to run any test cases or test suites because of the error:
java.lang.NoClassDefFoundError: Could not initialize class internal.GlobalVariable

Can anybody help me?

Updated: If reopen Katalon Studio, I can run everything again. However, I thinks it’s still an annoying bug and should be fixed.


I hate to exhume this ugly and dreadful thread but seems I have to.

I’m running KS 5.4.2 because of this bug. Yes, I know, that’s ancient, but I have no choice due to time constraints.

I tried updating to 5.8.x a while back and gave up trying to resolve this issue.

This morning I tried 5.10.1 thinking "surely they’ve fixed this problem by now?”

Nope: “Could not initialize class internal.GlobalVariable” and “cannot resolve class internal.GlobalVariable” etc (I may have mixed up the initialize/resolve elements but you get the idea).

When oh when is this god-forsaken bug going to be fixed? :rage:

Sorry. I’m angry. Another two hours of my life I won’t get back.

In 5.10.2 it’s supposed to be just a warning without any real effect. Did your execution finish successfully?


Thanks Alex.

No, it bombs out even before the test gets going.

I tried a simplistic test, something like:


which worked as you said but with a bunch of red lines (all of which will appear in reports so that’s not usable). But none of my tests run – they bomb out on custom classes and never get to a real test case line.

While I haven’t followed this topic for a while (and there’s no way I have time to read through it again :expressionless:), I’d like to take a shot in the dark and share what worked for me way back in June of last year. I haven’t experienced this issue in any release since 5.5.

In the file explorer, navigate to your project folder and delete the following items (no risk here, these will get re-built once you reopen the project in the Studio):

Then, try downloading the latest release (5.10.1 still I believe?) and open your project (it may take longer than normal to open, as you’ll see that these 4 directories are getting rebuilt, among other things), and run your script(s). @Russ_Thomas I’m curious to see if that makes any difference for you, as I’ve used it as a cure-all of sorts whenever the studio is acting strangely. Again, a shot in the dark, but it works for me :slight_smile:


Okay, I’m biting the proverbial bullet…

Looks to be the same. I cleared the files/folders as you suggested, Brandon. I tried running a single real-world test and got this immediately:

I clicked “Proceed” and bang.

SLF4J: The requested version 1.7.16 by your slf4j binding is not compatible with [1.6]
SLF4J: See for further details.
2019-01-17 13:55:00.678 e[34mINFO e[0;39m e[36mc.k.katalon.core.main.TestCaseExecutor -e[0;39m e[39m--------------------e[0;39m
2019-01-17 13:55:00.681 e[34mINFO e[0;39m e[36mc.k.katalon.core.main.TestCaseExecutor -e[0;39m e[39mSTART Test Cases/Pages/Misc/Test Access The Big Foure[0;39m
2019-01-17 13:55:01.135 e[1;31mERRORe[0;39m e[36mc.k.k.core.context.internal.TestHooker -e[0;39m e[31m❌ org.codehaus.groovy.runtime.InvokerInvocationException: java.lang.Error: Unresolved compilation problem: e[0;39m
2019-01-17 13:55:01.281 e[1;31mERRORe[0;39m e[36mc.k.k.core.context.internal.TestHooker -e[0;39m e[31m❌ org.codehaus.groovy.runtime.InvokerInvocationException: java.lang.NoClassDefFoundError: Could not initialize class internal.GlobalVariablee[0;39m
2019-01-17 13:55:01.725 e[39mDEBUGe[0;39m e[36mtestcase.Test Access The Big Four -e[0;39m e[39m1: trye[0;39m
2019-01-17 13:55:01.726 e[39mDEBUGe[0;39m e[36mtestcase.Test Access The Big Four -e[0;39m e[39m1: home = new com.xxxxxx.home()e[0;39m
2019-01-17 13:55:01.779 e[1;31mERRORe[0;39m e[36mc.k.katalon.core.main.TestCaseExecutor -e[0;39m e[31m❌ try FAILED.e[0;39m
e[31mjava.lang.NoClassDefFoundError: Could not initialize class internal.GlobalVariable

I think we can safely ignore the first two (right @devalex88?)

This seems a little more readable. Note the base classes and complaints from java:

java.lang.NoClassDefFoundError: Could not initialize class internal.GlobalVariable
	at com.xxxxxx.basePage.<init>(basePage.groovy:50)
	at com.xxxxxx.home.<init>(home.groovy)
	at Test Access The Big Access The Big Four:110)
	at com.kms.katalon.core.main.ScriptEngine.runScriptAsRawText(
	at com.kms.katalon.core.main.TestCaseExecutor.runScript(
	at com.kms.katalon.core.main.TestCaseExecutor.doExecute(
	at com.kms.katalon.core.main.TestCaseExecutor.processExecutionPhase(
	at com.kms.katalon.core.main.TestCaseExecutor.accessMainPhase(
	at com.kms.katalon.core.main.TestCaseExecutor.execute(
	at com.kms.katalon.core.main.TestCaseMain.runTestCase(
	at com.kms.katalon.core.main.TestCaseMain.runTestCase(
	at com.kms.katalon.core.main.TestCaseMain$runTestCase$ Source)

Out of pure inquisitiveness, I repeated the exercise: closed down Katalon, killed the bin and libs folders and the .classpath and .project files and tried again.

This time I saw this during loading of the project:


It sat there for almost three minutes (I watched the clock for over two of those minutes). Then , just as I was reaching for my gun, the project came up.

Ran the same test, got the same error.

Do you consistently get the “Errors in Workspace” dialog? If so, you should check the Problems tab and resolve any compilation errors. Basically by deleting those directories and reopening the project, you’re recompiling all of the project code from source, which is why you get the “Building workspace” dialog and the project takes longer to open.


I did. Empty. Plus, of course, this project compiles and runs fine each time I revert to 5.4x and runs on my real dev env (I’m testing this 5.10 release on a clean env on a win10 laptop).


Hey - thanks for your diligence, Brandon.

1 Like

Alright, one last stab at it, then I’ll leave it to the devs and stop chirping :smile: This is actually from early on in this same topic:

but the general idea is still the same. The GlobalVariable.groovy file should live in the directory path/to/my/project/Libs/internal:

If it isn’t there (for whatever reason, who knows), try creating a new project, grab the GlobalVariable.groovy file from that same directory in the new project, and pasting it back into yours. It can then be picked up by the compiler and added to your project.

Hope I’m not being overbearing here, I just remember how frustrating this particular issue was for me, and looks like continues to be for others. :persevere:

Hell no.

Precisely. It’s the most enduring/embarrassing bug on the forum and has been for waaaay too long.

Trying your last, now…

Nope. GlobalVariable.groovy was present in the libs\internal folder.

I went through the exercise anyway, watched Katalon overwrite the default 2KB file with mine as it rebuilt it from my project’s profile. Same issue.

Looks like I’m stuck with 5.4x. Again. Shame.

Thank you @Russ_Thomas @Brandon_Hein. My previous comment is for command line mode. May I see your internal.GlobalVariable content (without any modification)? It might help us fix this bug for good. You can send it to

Dear @Russ_Thomas,

We have recently had some updates in 5.11 to deal with this issue. Will send you the beta package for verifying soon.

Best regards,

Tested 5.11.0-beta. Exactly the same result as 5.10x :sob:

@Russ_Thomas I’m still pretty convinced that there’s some discrepancy between your particular project code and the later versions of the studio. If you create a brand new project in 5.10.1 (or the 5.11.0 beta), and write a quick test case that somehow uses the GlobalVariable class, I’m almost positive you will not have a problem. Maybe this would test it?:

1.) Add a test url in the default profile:

2.) Simple test case that uses this var:

import com.kms.katalon.core.webui.keyword.WebUiBuiltInKeywords as WebUI
import internal.GlobalVariable as GlobalVariable


If that works, then in my mind the best path forward would be to generate a brand new project using 5.10.1, then bring all of your current project code into the new project. Tedious for sure, but it might be the best option.


Yes, me too, Brandon. But…

1 - It’s legal groovy (we think)
2 - Katalon (@YoungNgo and @devalex88) have my GlobalVariable stuff to dissect.

Plus they’re welcome to log on to my box anytime (as Dung has done before).

Dung was hopeful that .11 might inch them closer to finding the cause but on the face of it (the results anyway) I don’t see any change.

For now, I’m content and in favor of letting them debug it while longer.

If I had the time (because I’m a crazy person) I’d consider loading old versions one-by-one to do a proper “which version killed me” test. That way they might get closer to a series of suspect commits. But I don’t have that time, right now.

Having said all of that, I’m slowly removing ALL GVs (only about half dozen to go). Then we’ll see if the GV complaint is real or just a symptom of something else (obviously, that would be the worst scenario).

Thanks again.