Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #420660 +++ Make the "effectively final" state of local variables available in ILocalVariable. (In reply to Jayaprakash Arthanareeswaran from bug 420660 comment #2) > I haven't introduced the API in ILocalVariable since it's not straight > forward in some of the cases, esp. when we recreate the element from the > memento or binaries.
Retargetting to 4.4, Will pull it up to Java 8 GA if time permits. If this is a must fix for March 18th release, let us know.
Markus, how important is this for the UI? At the moment I am seeing some obstacles in the way: 1. There would be scenarios where we construct the ILocalVariable without having resolved the CU, e.g CompilationUnitStructureRequester. This means we won't have a way of getting the effectively final bit without explicitly resolving the CU. 2. This one is a bigger issue. In certain cases, when we create the ILocalVariable (like hover), the complete flow analysis hasn't happened because not all statements in the block/method are resolved. In the selection requester/engine, we ignore most statements in the method and use a bogus place-holder AST to process the selection requests. At the moment, I don't know what we can do here. If there is no compelling reason, I would like this left as is, or at least move out of 4.4.
OK to drop from 4.4. It's not clear yet if and how we want to render "effectively final" in the UI. See bug 420665 and bug 421564 for two possible approaches. Only the former would need API on ILocalVariable. The API can also throw a JavaModelException and resolve the state lazily if it's not available when the handle is created.
