Community
Participate
Working Groups
Overview: When creating a new concrete instance of an interface type, the content assist does not suggest constructors for types that implement the interface. Steps to reproduce: Type the following: "java.util.List<String> foo = new " and trigger content assist with Ctrl-Space. Actual Results: Two options are presented - one is to auto-create an anonymous inner type implementing List<String>, the other option is to invoke the constructor of my enclosing class. Expected Results: To be offered constructors for all the known types that implement the interface. I.e. the same list of classes that would be shown if I viewed the type hierarchy of List. Build Date & Platform: Build id: 20120614-1722 (64-bit Debian Squeeze) Additional Builds and Platforms: I don't believe this has ever been a feature of Eclipse, so would be present in all builds to date.
This would be too expensive/slow. However, we do remember what you used previously and suggest that in the future.
(In reply to comment #1) > This would be too expensive/slow. But I feel that the current behaviour is not helpful at all. I, for one, would certainly appreciate a "slow" alternative that is more functionally useful. I'm only referring here to the exact case described above, in which the user is invoking content assist after having typed the "new" keyword. > However, we do remember what you used previously and suggest that in the future. How exactly is that behaviour triggered? For example, I tried the following: List<String> foo = new ArrayList<String>(); foo = new ... and hit Ctrl-Space. I was not offered a suggestion of ArrayList<String>().
cc'ing Marcel, in case something of this sort is possible in Code Recommenders or if it is already there.
(In reply to comment #3) > cc'ing Marcel, in case something of this sort is possible in Code Recommenders > or if it is already there. FWIW, we'll have one student starting in October who aims to improve type completion proposals. We probably won't suggest all available subtypes but a set of the most likely ones (List l = new |<^space> will likely be filled by LinkedList or ArrayList). We track progress of this feature in Bug 384443.
(In reply to comment #4) > We track progress of this feature in Bug 384443. That looks like a different bug, but anyway marking this as a duplicate of that one so that this usecase is also tracked there. *** This bug has been marked as a duplicate of bug 384443 ***
(In reply to comment #4) > We probably won't suggest all available subtypes but a > set of the most likely ones (List l = new |<^space> will likely be filled by > LinkedList or ArrayList). I realise this feature is likely to be unplanned at the moment, but would you suppose this "likeliness" is determined programmatically, e.g. by reference counting throughout the project? If not, then I suppose it must be a hard-coded list of candidates and thus only suitable for completion of built-in java.* types? I'm trying to determine if this student's work will solve my issue or whether I might consider addressing it with a plugin of my own.
(In reply to comment #6) > would you > suppose this "likeliness" is determined programmatically, e.g. by reference > counting throughout the project? In step one, the likeliness is determined by how often we have seen assignments of the form List l = new X in our example code base and generate a (fixed) model from that. You may specify your own models manually and use them as replacement for those we will offer in future. > I'm trying to determine if this student's work will solve my issue or whether I > might consider addressing it with a plugin of my own. You may want to start working on the skeleton completion engine now (possibly in the scope of the recommenders project) that uses a hardcoded set now and switch to a more flexible scheme we'll provide some time later this year. If you are interested in implementing this, feel invited to continue the discussion on this at recommenders-dev mailing list ;-) Best, Marcel I silently assume what Code Recommenders is and how it works. Let me know if this assumption is wrong.
