-
Bug
-
Resolution: Fixed
-
P3
-
7
-
b132
-
unknown
-
generic
-
Verified
There are a bunch of places in which a listener infrastructure will come very handy when dealing with javac scopes:
*) Types.implementation/Types.membersClosure cache - those two caches need to be invalidated if the scope of a given symbol is changed (i.e. a symbol is added/removed) at a later stage (i.e. during lowering). Note that this is not normally the case (all members are entered in MemberEnter/ClassReader on demand when calling TypeSymbol.members()).
*) To cleanup the fix of 6996626 (issues with import scopes). This fix partially relies on a proto-listener infrastructure in order to get notifications from the removal of symbols from a package scope.
*) Types.implementation/Types.membersClosure cache - those two caches need to be invalidated if the scope of a given symbol is changed (i.e. a symbol is added/removed) at a later stage (i.e. during lowering). Note that this is not normally the case (all members are entered in MemberEnter/ClassReader on demand when calling TypeSymbol.members()).
*) To cleanup the fix of 6996626 (issues with import scopes). This fix partially relies on a proto-listener infrastructure in order to get notifications from the removal of symbols from a package scope.
- relates to
-
JDK-6996626 Scope fix issues for ImportScope
-
- Closed
-
-
JDK-7036906 Scope: CompoundScope.getElements() doesn't pass scope filter to subscopes
-
- Closed
-