Community
Participate
Working Groups
Using RC2 candidate I20050610-0010, while verifying bug 85384. '|' mark position of code completion in following test cases. 1) public class X<T extends Str| Code assist does not propose String as it is a final class => correct 2) public class X<T extends Object> { void <U extends Str| } In this case, code assist propose String although it should not
i cannot reproduce 1) and currently there is no special support for final classes in codeassist. But that's real bug. final classes should not be proposed. Similar test case found by Frederic: class X extends Str|
comment 0 test case 1) was definitely wrong... String is proposed but not on top of the list In fact, I think I typed: public class X<T extends St<|> and didn't see String as the list as a little bit long...
(In reply to comment #1) > i cannot reproduce 1) and currently there is no special support for final > classes in codeassist. > But that's real bug. > final classes should not be proposed. Since <T extends SomeFinalClass> is not a null set, but the singleton set SomeFinalClass, it may not be totally wrong to suggest final classes in these cases ? Personally, I think we should NOT propose final classes, but just checking. > Similar test case found by Frederic: > class X extends Str| There is no uncertainty here: we should not propose final classes here. I have a patch for both, that is under test.
(In reply to comment #3) > Since <T extends SomeFinalClass> is not a null set, but the singleton set > SomeFinalClass, it may not be totally wrong to suggest final > classes in these cases ? > > Personally, I think we should NOT propose final classes, but just checking. I agree. Even if it is not totally wrong, propose SomeFinalClass is useless. If a user want to use SomeFinalClass he should write class X { void foo(SomeFinalClass p) {} } and not class X<T extends SomeFinalClass> { void foo(T p) {} }
Created attachment 126839 [details] Proposed fix + tests We don't propose final classes anymore in ''extends'' contexts (type declarations, typeparameters, wildcards etc).
Created attachment 127156 [details] Revised patch Earlier patch had a couple of problems: - There was a serious bug due to misunderstanding of "expected types". - The rejection of final classes in extends contexts is handled differently now - along the lines of rejecting interfaces where classes are expected.
Created attachment 127304 [details] Revised patch Improved patch : Moved some computations out of the critical path.
Comment on attachment 127304 [details] Revised patch This patch is OK for me
Released for 3.5M6.
Verified for 3.5M6 using I20090310-0100.
