Community
Participate
Working Groups
R3.1 Have CU A.java: class Outer {} public class A { class Inner {} int i; void foo() { int j; <caret> } } Code assist returns 'i' and 'j' but not inner type 'Inner'. In addition it should also propose 'Outer'. This is a code assist deficiency which gets mentioned often (recently on JavaLobby).
Dani - In this case, Code assist should return all types or only types in the same compilation unit ?
This behavior was changed as part of some polish work. We could provide an option for backward compatibility.
All types would be too much. Those defined in the CU plus those used in the CU would be a good guess.
I would just revert the old behavior. Now the problem is that introducing an option could be problematic for 3.1.1, so we should simply revert the old behavior there, and make it optional only in 3.2 branch (leaving empty type completion on by default).
>This behavior was changed as part of some polish work. Can you explain which one that was and whether this polish work would be removed as well? If so, we'd have to decide what's worse.
The old behavior: When completion token is empty only expected types and enclosing types are proposed. An expected type is a type that can be guessed like inside a variable initialization (X x = |) or an assignemnt (x = |). The current (polish) behavior: When completion token is empty no types are proposed, unless the completion is inside a constructor invocation name (X x = new |) . If the completion is inside a constructor then only expected types are proposed. The polish item was: Either present all types on an empty prefix or none. The current behavior is to show only some types (parent type and current inner types). This is irritating and lead to unwanted auto inserts. e.g bug 92555.
To complete an empty token there is a lot of possibilities. 1) propose all types. -> too much proposals. 2) propose nothing. -> doesn't seems to be a good solution (bug 95505). 3) propose only expected types. 4) propose only enclosing types. 5) propose expected types and enclosing types. -> it is the old behavior which was removed during the 3.1 polish work. 6) propose nothing or expected types if the completion is inside a constructor name. -> it is the current behavior which was added during the 3.1 polish work. 7) propose expected types or propose enclosing types if there is no expected types. 8) if the completion is inside a constructor name then propose only expected types or enclosing types if there is no expected type. otherwise propose enclosing type and expected type. 9) ... For 3.2 we can add an option to switch between several of these possibilities but for 3.1.1 we must choose only one of them. I think that the current behavior is sufficient (6). My second choice would be (5) or (8) but (6) is slightly better. If the behavior is (5) or (8) then with the following test case only X will be proposed (and inserted if automatic insertion is enabled) and this completion will be rarely the wished one. That's why i prefer (6). class X { | } Another reason to keep (6) is because change the current behavior could potentially introduce some new bug in 3.1.1. Daniel, tom, what is your opinion about that for 3.1.1 ?
- I like the way it is currently (6). - I see that other opinions are valid as well... - I wouldn't change for 3.1.1 - An option may make sense for 3.2
I'd simply like to get the 3.0.2 behavior back where I get 'A', 'Inner' and 'Outer' i.e. 5) but I don't think it is something we must have for 3.1.1. Personally I'm against adding a new preference even if we decide to go with 6) Wasn't it possible to only change the annotation code assist scenario as outlined in bug 92555?
I removed the 3.1.1 target milestone. Daniel - I don't understand what you mean by 'code assist scenario as outlined in bug 92555'.
Ah, I see: you only mentioned bug 92555 as an example and not as being the polish item itself.
Discussed at the JDT Summit: the original polish bug was about completion after '@' where annotation types should have been proposed or nothing and not all expected types. The polish work got extended to all empty completion scenarios which is not good. We should - check whether the '@' scenario (bug 92555) can be improved - bring back expected types in the other empty completion cases
Perhaps I am missing something, but: expected type completion with empty prefix works fine for me in I20060704: // 'String' gets proposed class X { void m() { String s= new | } } The behavior requested in comment 0 is a dup of bug 95505, which was fixed by bringing expected types back (as above), but did not bring completion for inner or enclosing types back, which is a good thing IMO. So, I believe this is fixed
Not fixed, simply check comment 0. David, please continue as discussed at the summit.
(In reply to comment #14) > Not fixed, simply check comment 0. David, please continue as discussed at the > summit. Hm, as outlined in bug 95505, I think the behavior requested in comment 0 is inconsistent and arbitrary. But if I am the only one that feels this way... go ahead.
Thanks for the blessing Tom ;-)
Ok, completion engine will propose types which are in the current compilation unit.
Released for 3.3 M1. The released behavior is the old behavior: when completion token is empty, enclosing types and expected types are proposed.
I assume that you verified not to break bug 92555.
Only annotations are proposed behind a @.
Verified for 3.3 M1 using build I20060804-0010. One thing is that while verifying if bug 92555 was not broken, I noticed that public class FooTest { @<|> } does not give any proposal and I don't know if this is the expected behavior or not...
