Repository navigation
Uncaught ReferenceError: TEk_g$ is not defined SuperDevMode #9565
Description
Activity
Can you fill out the rest of the bug report? Without your steps to reproduce the issue, we don't know what aspect of your application is exposing this bug in GWT - normal usage of loggers does not cause this.
Ideally, build a very small application, just a .gwt.xml file and an entrypoint to show this. All I can see so far is that this is probably happening right in your onModuleLoad.
I'm seeing this issue as well in GWT 2.8.2. It has something to do with lambda expression; some work while other don't. Compilation works fine, including superdevmode. It fails when you try to execute the component where the lambda is used.
In my case, the lambda itself it pretty simple; just a one liner that doesn't return a value or need any braces:
textBox.addValueChangeHandler(event -> model.setValue(event.getValue()));I wish I could pinpoint the exact reason why I see the error: ReferenceError: B$H_g$ is not defined. it happens sometimes if there is another lambda expression before. If you change the first lambda to an anonymous class it works; or if you add braces to the second lambda it works as well.
Reacted by Sean FlaniganAside from also getting JS's useless "that is null, don't try to use properties on it" error message, its unclear if there is any overlap with the existing issue (as it didn't involve lambdas at all)
Can you add a little more detail about what you are seeing? Exactly what is the B$H_g$ method in the example given, can you run SDM in style=PRETTY so we can more easily read the JS?
If the issue is reproducible with/without braces, can you try making a small example project showing this?
Finally, does deleting the gwt-unitCache or doing a clean build help resolve this?
I just ran into this and deleting the codeserver's
/tmp-files helped.Yep, deleting the tmp files resolved it for me as well
Ran into this on GWT 2.12.2 and root-caused it. It's stale persisted incremental-compile state, which explains the earlier comments where deleting the code server's tmp files resolved it.
CodeServer unconditionally persists the unit cache and MinimalRebuildCache to
${java.io.tmpdir}/gwt-cache-<md5(cwd + module names)>(DiskCachingUtil.computePreferredCacheDir), which survives code-server restarts. When a source file's lambdas are renumbered between sessions (a lambda added/removed earlier in the file), the next compile merges stale per-type JS with fresh output. With-style PRETTYwe caught a single compile containingnew AceEditorWidget$lambda$2$Type_2_g$(this)(the current lambda #2) while the only definition present wasfunction AceEditorWidget$lambda$2$Type_1_g$(cursorRow...)-- a different lambda that was #2 in an older revision of the file. Across the class, definitions were a mix of two name generations (_1_g$for lambdas 0/1/2,_2_g$for 3/5/6), with the fresh definitions for #2 and #4 dropped entirely -- presumably because the cache already held types under those binary names -- while their call sites got fresh disambiguated global names. Result:ReferenceError: <Class>$lambda$N$Type_2_g$ is not definedat runtime, even after a "clean" code-server launch, since the cache lives outside any project directory.Expected repro from this mechanism: compile a module under SDM with incremental on, stop the code server, add a lambda earlier in a file that already contains several, restart, reload.
Workarounds: the code server's
/cleanendpoint, deleting$TMPDIR/gwt-cache-*, or-noincremental. Full compiles are unaffected.#10323 is expected to fix this.
Thanks; I checked #10323 against the reproduction from my earlier comment, and unfortunately it doesn't resolve this particular failure mode. I applied #10323 to main (without the fix from #10390) and ran the three-step repro; it still produces Widgets$lambda$2$Type_2_g$ is referenced but never defined.
I believe the two fixes are complementary. #10323 fixes staleness marking: it records synthetic lambda/methodref types as nested types of their unit, so they properly enter the stale set when the unit is modified (previously they were missing entirely). But the failure here happens one step later: computeAndClearStaleTypesCache() filters the stale set against the previous compile's reachability before clearing cached JS, so a stale type that was unreachable in the last compile keeps its outdated JS, and UnifyAst.needsNewJs() splices it back into the output once the type becomes reachable again. That ordering is what #10390 changes (clear first, then filter what gets force-retraversed).
With both applied, the regression test in #10390 passes; with only #10323, it fails.
Thanks, I'll take a closer look at the test you added - it seems in principle to be the same issue, but it must cover some other path missed before. I did end up with two other candidates for fixing the original issue that looked like they could be improperly cleaned, but neither ended up making a material difference, so I'll recheck them with this example
- added a commit that references this issue
on Aug 20, 2026
GWT version: 2.8.2
Browser (with version): Chrome 61
Operating System: Windows 10
Description
I am getting this Exception while running the SuperDevMode with Intellij :
P2c_g$ z2c_g$ z1c_g$ initializeModules_0_g$ i1_g$ l1_g$ (anonymous function) S0c_g$ (anonymous function) Uncaught ReferenceError: TEk_g$ is not definedin com.google.gwt.logging.client.LogConfiguration.java at line
While application is running fine when deployed on tomcat server (without SuperDevMode)
Steps to reproduce
1. Deployed my application on Tomcat9
2. I am running the SuperDevMode with parameters
-noprecompile, -port, 9876, -sourceLevel, 1.8, -bindAddress, 127.0.0.1, -launcherDir, D:\random\apache-tomcat-9.0.0.M21\webapps\, -logLevel, INFO, -style, OBFUSCATED, com.web -startupUrl http://localhost:8090/ -noserver -war D:\random\apache-tomcat-9.0.0.M21\webapps\3. I am using Intellij to debug the application
4. As soon as it launches on chrome, it through this error on console and the startup page doesn't load
Known workarounds
Switching back to GWT 2.8.0 solves the issue
Links to further discussions