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.
Let's say that you have the following code: List myList = new ArrayList(); myList.size(); currently, when I'm trying to use the "go to source" mechanism on 'size()', it takes me to List.size() (the interface). I would have liked it to take me to ArrayList.size().
myList is declared as List not ArrayList. That's the reason why "go to source" leads you to the impl of List.size().
I know, but getting me there is usually of no interest. Is there a problem enhancing the behavior to do that? I remember JBuilder does that.
Hi, as a first thing - I do not think this is a defect, I think it was designed to work this way. I will mark this issue as enhancement. Mark as defect if you disagree. To the question - I understand why do you want this. Sometimes, I feel I would use such feature. But, I am not sure how to generaly find out the content of a variable without executing the program with given arguments and user input. Consider following code: public void test(boolean useArray) { List list; if (useArray) list = new ArrayList(); else list = new Vector(); list.size(); } Here is impossible to find out what will be the object referenced by "list". The only think we *can* (in general, not in today code) do is to find the variable content when it is "simple" to find it. And that would mean: 1. This feature will work only sometimes (it is only heuristic). I do not like such features. 2. Parse/analyze method body. I am affraid that this is much, much work. Martin, Mila, what do you think about it? In all cases, I do not think this is "simple to implement" feature.
Why don't you like the heutistic aproach? TMHO it's better to do a better job most of the time, than to give up and say that you're not going to do anything at all because you know that you're going to fail sometimes...
Guys, will you implement this enhancement on your own, or should I make this dependent on RFE for complete metamodel of java source ?
To first question - I do not like heuristic approach, because it will probably pass and fail in very similar cases (little or no difference for human), so one can not rely on it. I mean, you can rely on word matching and on abbreviations for 100%. You could rely on basic code completion on (say) 90%. But you could not rely on such heuristic approach, it will not be sure that you will have good result, or even any result at all. And I do not like features I can not rely on. There are other reasons (less important), like that it is nearly untesteable. For Svata's question - I can not speak for Mila, but I think that parsing method body in editor module would be quite bad solution (impact on performance and bugs count would be probably significant), so we probably should wait for metamodel and get needed information from it. Svata, please, can you make this dependent on the "metamodel" issue? (I did not find it, sorry.) Mila, do you agree?
I agree. If it helps to people let's do it, but I understand that it makes Honza a little nervous. We need to document the process of finding the assigned type so that it's testable by QA.
Is this really targeted for 3.3.1?
when do you expect to start seeing any progress on this?
Set target milestone to TBD
Changing subcomponent to navigation.
*** This issue has been marked as a duplicate of 142112 ***