This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 98044 - java code completion & generics not working as expected
Summary: java code completion & generics not working as expected
Status: RESOLVED DUPLICATE of bug 98041
Alias: None
Product: editor
Classification: Unclassified
Component: Completion & Templates (show other bugs)
Version: 6.x
Hardware: Sun All
: P3 blocker (vote)
Assignee: Dusan Balek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-15 22:25 UTC by _ pcw
Modified: 2007-11-05 13:38 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ pcw 2007-03-15 22:25:56 UTC
Given the expression "ConcurrentMap<X, Y> testMap = new Concurrent^",

if you hit ctrl-space (twice, see issue 98041) at the ^ mark to get code
completion, select ConcurrentHashMap, and completion will insert
ConcurrentHashMap at the editor mark.

What it should have inserted was "ConcurrentHashMap<X, Y>", as 99% if not 100%
of the time, that is what the user is going to type next.  There might be some
pathological edge cases where the classes will vary, but I can't think of any
legit use case for that right now.  Certainly would be the small minority if
it's valid at all.
Comment 1 Jiri Prox 2007-03-16 09:41:44 UTC
It should work, the generics are completed when item is selected from normal
code completion (pressing ctrl-space just once - see comments in issue 98041).

What is not working now is following usecase:

package pack;
import java.util.List;
public class MyClass<X> {
    List<X> list= new Linked|    
}

when CC is invoked at position marked by | it will not add LinkedList<X> but
just LinedList (e.g w/o generics)
It's ok when the X in "list" type is changed to some existing class (e.g String)

--
NetBeans IDE Dev (Build 200703151900)
1.6.0; Java HotSpot(TM) Client VM 1.6.0-b105
Linux version 2.6.5-1.358 running on i386
en_US (nb); UTF-8
Comment 2 _ pcw 2007-03-16 09:53:40 UTC
Well, it didn't work.  My build is from 3/12, if that matters, running on JDK 6
B105, Solaris x86 11/06.

ConcurrentMap was not imported since I had to hit ctrl-space twice, but that
should not have made a difference here as there was enough context to figure out
what I wanted.
Comment 3 Dusan Balek 2007-03-16 11:17:06 UTC
The 'List<X> list= new Linked|' case fixed. The first case is duplicate of #98041

Checking in JavaCompletionItem.java;
/cvs/java/editor/src/org/netbeans/modules/editor/java/JavaCompletionItem.java,v
 <--  JavaCompletionItem.java
new revision: 1.38; previous revision: 1.37
done

*** This issue has been marked as a duplicate of 98041 ***
Comment 4 _ pcw 2007-03-16 20:10:01 UTC
I disagree, this is not a duplicate.

My complaint here is that when I type "ConcurrentMap<X, Y> = new Concurrent^"
and use code completion (twice) to tell the IDE I want to use a
ConcurrentHashMap, the IDE should fill in BOTH the full classname AND the
generic type arguments.

IOW, the inserted text should be "ConcurrentHashMap<X, Y>".  Not merely
"ConcurrentHashMap".

From your comments on 98041, it sounds like the code is currently written to say
"I don't know what type ConcurrentMap<X, Y> is because it's not imported,
therefore I will do nothing".

I do not know much about the new source model, but it seems to me there should
be enough context to determine what the correct answer is, even when if
ConcurrentMap is not imported by the java file.

If this cannot be done or is too much work, then I guess it gets closed as WONT
FIX, but it's not a duplicate of 98041.
Comment 5 Dusan Balek 2007-03-19 13:00:29 UTC
The new Java source model is based on using the 'javac' compiler to get all the
information about your source - whenever code completion is invoked, the 'javac'
is run to get the context. Now, if the code completion infrastructure gets the
information that the parameterized type 'ConcurrentMap<X, Y>' is the type on the
left side of the assignment, 'ConcurrentHashMap<X, Y>' will be offered
(including type parameters) on the first Ctrl+Space. However, if the
'ConcurrentMap' is not imported yet, the 'javac' tells the completion
infrastructure that the type on the left side of the assignment is 'unknown'. In
this situation, code completion infrastructure offers either imported types (on
the first Ctrl+Space) or all types on the classpath (second Ctrl+Space) both
without type parameters (code completion does not know that there are any).

The issue here is whether the code completion infrastructure should try to
resolve types using some alternative approach in the case that 'javac' is not
able to do it (e.g. due to missing import statements). That's why I think that
this issue IS in fact a duplicate of #98041.

*** This issue has been marked as a duplicate of 98041 ***