Skip to main content
Jump to: navigation, search

Difference between revisions of "JDT Core Programmer Guide/ECJ/Lookups"

(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...")
 
(Scopes)
 
Line 47: Line 47:
 
A TypeDeclaration may hold additional scopes <code>initializerScope</code> and <code>staticInitializerScope</code> for resolving field initializers (implementation uses MethodScope also here).
 
A TypeDeclaration may hold additional scopes <code>initializerScope</code> and <code>staticInitializerScope</code> for resolving field initializers (implementation uses MethodScope also here).
  
 +
Each scope has a '''parent''' link to support inside-out searches during resolution.
 
''TBC''
 
''TBC''
  
 
[[Category:JDT]]
 
[[Category:JDT]]

Latest revision as of 16:16, 4 July 2020

Note.png
During name resolving, several structures are used to identify the binding referenced by a given name.


LookupEnvironment

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 :

TBC

ModuleBinding

Since Java 9 also module bindings act as lookups.


TBC

PackageBinding

TBC


Scopes

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).

Each scope has a parent link to support inside-out searches during resolution. TBC

Back to the top