Skip to content

Uncaught ReferenceError: TEk_g$ is not defined SuperDevMode #9565

Description

@prem6667

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 defined

in com.google.gwt.logging.client.LogConfiguration.java at line

this.root = Logger.getLogger("");

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

Activity

  1. niloc132 commented on Oct 31, 2017

    @niloc132
    Member

    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.

  2. udeleng commented on Nov 1, 2018

    @udeleng

    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.

  3. niloc132 commented on Nov 1, 2018

    @niloc132
    Member

    Aside 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?

  4. lglowania commented on Apr 21, 2019

    @lglowania

    I just ran into this and deleting the codeserver's /tmp-files helped.

  5. tbuckel commented on Oct 31, 2019

    @tbuckel

    Yep, deleting the tmp files resolved it for me as well

  6. kevinushey commented on Aug 10, 2026

    @kevinushey

    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 PRETTY we caught a single compile containing new AceEditorWidget$lambda$2$Type_2_g$(this) (the current lambda #2) while the only definition present was function 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 defined at 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 /clean endpoint, deleting $TMPDIR/gwt-cache-*, or -noincremental. Full compiles are unaffected.

  7. niloc132 commented on Aug 10, 2026

    @niloc132
    Member

    #10323 is expected to fix this.

  8. kevinushey commented on Aug 11, 2026

    @kevinushey

    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.

  9. niloc132 commented on Aug 11, 2026

    @niloc132
    Member

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions