Hi,
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
java.io.FileNotFoundException: http://s3.amazonaws.com/katalon/update/5.9.1/macosx-x86_64/contents.tar.gz
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
java.io.FileNotFoundException: http://s3.amazonaws.com/katalon/update/5.9.1/macosx-x86_64/contents.tar.gz
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.
Regards
1 Like
Hi,
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.
2 Likes
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? 
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:
WebUI.openBrowser("www.google.com")
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 
), 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 
2 Likes
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 SLF4J Error Codes 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[31mReason: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:
try FAILED.
Reason:
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 Four.run(Test Access The Big Four:110)
at com.kms.katalon.core.main.ScriptEngine.run(ScriptEngine.java:194)
at com.kms.katalon.core.main.ScriptEngine.runScriptAsRawText(ScriptEngine.java:119)
at com.kms.katalon.core.main.TestCaseExecutor.runScript(TestCaseExecutor.java:328)
at com.kms.katalon.core.main.TestCaseExecutor.doExecute(TestCaseExecutor.java:319)
at com.kms.katalon.core.main.TestCaseExecutor.processExecutionPhase(TestCaseExecutor.java:298)
at com.kms.katalon.core.main.TestCaseExecutor.accessMainPhase(TestCaseExecutor.java:290)
at com.kms.katalon.core.main.TestCaseExecutor.execute(TestCaseExecutor.java:224)
at com.kms.katalon.core.main.TestCaseMain.runTestCase(TestCaseMain.java:106)
at com.kms.katalon.core.main.TestCaseMain.runTestCase(TestCaseMain.java:97)
at com.kms.katalon.core.main.TestCaseMain$runTestCase$0.call(Unknown Source)
at TempTestCase1547754895203.run(TempTestCase1547754895203.groovy:22)
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.
No.
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).
Crazy.
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 
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. 
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 info@katalon.com.
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 
@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
WebUI.openBrowser(GlobalVariable.url);
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.
Thanks.
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.