Community
Participate
Working Groups
I20031105 After talking to Jerome, reading the Javadoc and discussing within the JDT UI team we still consider it a bug that the exists() method returns false: - it is not logical that the element whose parent exist doesn't exist - wouldn't sort of a synthetic flag be better? - how can we know if the local still exists? Do we have to ask the parent?
- it is not logical that the element whose parent exist doesn't exist Wrong. You can create a method handle whose parent is an existing type without the method existing. - wouldn't sort of a synthetic flag be better? What do you mean? - how can we know if the local still exists? Do we have to ask the parent? It never existed. It doesn't exist. It will never exist. This is just a pseudo- element resulting from a codeSelect(...). Its lifetime is 0. You cannot use it outside the operation that created it. Never keep a reference to it.
Alternatively, it could always answer true if the enclosing method exists.
However, I agree with Jerome that you shouldn't be persisting these, and have to ask yourself questions such as #exists(). What are you trying to do ?
I was running through existing code (of which we have a lot) but stuff (in my case adapted code for getting the JavaSourceHover and JavaElementLabels) for the local variable never showed up. The reason was that we test for IJavaElement.exists where it falls through. This basically means that ILocalVariable (returned for existing elements) will never pass any of our JDT UI code that is protected with exists().
Right, you need to change this code
Can't we be optimistic and explain that variable elements are living until the code is changed again. Thus until this occurs, it will always pretend it exists by default. I suspect it could be protected by saying that it exists as long as its enclosing element exists, but this is just to be nice.
We have no way to know that the code changed under the local variable handle. It is not a child of its method.
I agree, though for the same reason it could just pretend to exist all the time (equally wrong, but lees suspicious to clients ?). No strong opininon. If always true, then IJavaElement#exists API spec need to be tuned to describe this situation. Side-question: Dani, are you using the memento API of a local variable ? We suspect we shouldn't have provided it ever, since it incorrectly encourages clients to persist such handles for more than their expected life time (which is very short). Couldn't search results simply extract the info they need from elements, instead of storing the element memento ? Names + source ranges.
Dirk, please comment as well.
For me it feels wrong that exists always returns false for local variable, especially since they are IJavaElements. If an API returns IJavaElement the exist method for that Java element should return a "reasonable" value independent of the concert element that got returned. Meaning, if I do code resolve and get a local variable back, it exists and therefore #exists() should return true. Otherwise we always have to treat locals special which results in lots of instanceof checks. And how will we find out that a local "really" doesn't exist. A solution as outlined by Philippe in comment #6 is IMO the right path to follow.
Changed spec and behavior to return whether the parent exists.
Verified.
