Skip to main content
Jump to: navigation, search

JDT Core Programmer Guide/ECJ/Lookups

< JDT Core Programmer Guide‎ | ECJ
Revision as of 15:22, 2 July 2020 by (Talk | contribs) (Created page with "{{note|During name resolving, several structures are used to identify the binding referenced by a given name.}} ==LookupEnvironment== The central place where the following bi...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
During name resolving, several structures are used to identify the binding referenced by a given name.


The central place where the following bindings are globally stored:

  • ModuleBinding (knownModules)
  • PackageBinding (knownPackages, recursively)
    • TypeBinding (knownTypes)

Since Java 9, however, different instances of LookupEnvironment are used, to implement the perspective of one module each. In this situation

  • the root lookup environment represents the unnamed module
  • module-specific lookup environments are found via the environment field of elements of knownModules
  • each lookup environment has a back link root to the root environment
  • fields of LookupEnvironment that are not module specific are documented as either ROOT_ONLY or SHARED (see javadoc of LookupEnvironment#root).

Other "singletons"

The root lookup environment also links a few unique instances:

  • globalOptions : all compiler options in effect
  • nameEnvironment : sometimes called the oracle, since it's an external/opaque entity that can answer sought types and packages.
  • typeRequestor : callback for newly discovered types
  • typeSystem : manages variants of known type bindings (parameterizations, arrays, annotations)
  • verifier :
  • problemReporter : a fall-back problem reporter, which is used for reporting errors that cannot be associated to a particular AST node.
  • classFilePool :



Since Java 9 also module bindings act as lookups.





In addition to the global lookup (which serves source and binary elements), the following AST nodes have their dedicated Scope which performs the initial, location-aware part of name lookup:

  • CompilationUnitDeclaration -> CompilationUnitScope
  • ModuleDeclaration -> ModuleScope
  • TypeDeclaration -> ClassScope
  • AbstractMethodDeclaration -> MethodScope
  • Block -> BlockScope (also used by block-like nodes like ForeachStatement)

A TypeDeclaration may hold additional scopes initializerScope and staticInitializerScope for resolving field initializers (implementation uses MethodScope also here).


Back to the top