Yes, you are not doing it correctly. :)))

Fix your code this way:
List params = new ArrayList();
for (Iterator i = m.getParameters().iterator();
i.hasNext();params.add(((Parameter)i.next()).getType()));

return target.getMethod(m.getName(), params, false) != null;

Erm, sorry to reopen, but the getParameters() returns an instance of java.util.List, and the 
workaround suggested is to create another java.util.List with the same contents.  It's an 
API usability thing - nobody is going to expect that one list will fail, but the other will 
succeed - to the API consumer they're both just vanilla java.util.List's.

Couldn't the code that gets called check the class of the list, and if it's not java.util.*, do 
this itself?  I think when external people start writing modules to this API they'll have a 
hard time figuring out why using the list they got from getParameters() won't work, but a 
new ArrayList with the same contents will (I know why, but I'm not worried about me, I'm 
worried about people complaining about how hard it is to write modules for NetBeans).  

We've already got enough hard-to-use stuff in our APIs, we shouldn't torture people with 
more, and this ought to be easy enough to fix (even if the actual list class used isn't visible 
to the code that gets called, you can still check if it's not ArrayList or LinkedList, and 
create a new list if so - or implement clone() on the custom list class to do something like 
that).

Thanks for the info, though - I'll fix my code to use it.

It is not List with the same contents.
Method.getParameters() returns List of Parameters, while the new list
"params" is List of Types.

Duh! [slapping myself on forehead]

Well, it still would be nice to make the comparison painless, but what I did shouldn't work.

Reorganization of java component

reopen to fix status and resolution

fix status and resolution