Calling Methods

[marykay]

Hi ! Thanks for solving my previous problem. I have to change one method of the application. Before that, I want to find what other classes(or methods) are invoking this method. Is there any way I can do this. Please help me. THanks in advance.

[Goodz13]

Sorry to be so blunt, but what method are you talking about?

[marykay]

It is one method in my java application I am modifying. My question is, in general, is there any way to find out the methods that call a particular (say retrieveXXX()) method. Because, I don't know other parts of the application except the one I am working on. I need to see list of classes that call this method. Sorry and Thanks,

[dlorde]

The only way I know is to search through the source looking for the call. Some IDEs have excellent searching features that can find all usages of a method.

In principle, assuming the method signature isn't going to change, you shouldn't need to know who's calling it. Changing the implementation of a method should have no effect on callers (in terms of code).

Are you changing the signature of the method (i.e. its parameters and/or return value and/or exceptions) ?

Like many of the upper class, he liked the sound of broken glass...

[marykay]

Thanks, and Yes Dave! I need to change the signature as well. Do you think it is good to add an overloaded method with same name and different parameter? Thank you,

[Goodz13]

If your class is already in use, I would overload the method. Are you working in a shop or on your own? If your working in a shop with other developers and a project manager, isn't there procedures in place where you can get the info you desire?

[dlorde]

I agree with Goodz13. If you overload the method, existing caller code won't have to change.

Once you've decided on the public methods for a class and they're in use by other classes, you've effectively established a 'contract' that you should honour. However, there's no reason why you shouldn't extend the class with some additional 'contractual obligations' (methods) ;)

Having said all that, the latest development guidelines suggest you should refactor 'little and often', meaning that you should continuously review the design and fix problems as soon as you find them. If a mistake has been made in the design of the class and its methods, it's better to fix it immediately (even if this means changing the calling code) than let it fester in the code and cause confusion or problems later. This is far more practical now that the best IDEs have refactoring facilities that allow you to make changes that are automatically reflected through the whole application. Without such tools, it's really too tedious and error-prone to refactor non-trivial applications by hand.

I count him braver who overcomes his desires
than him who overcomes his enemies...

[marykay]

Thanks for your valueable replys Dave and GoodZ. Unfortunately, nothing has been written down about the application. That is why I am having hard time here refining the application. I am thinking to start it now. I should push my manager to buy such good IDEs. Can you please tell me some names of the IDEs ? I will do some research which one will be good for us. Again, Thank you very much.

[saddysans]

how about
taking backup of ur application,
than changing the method(only if it is extremly imp, otherwise overloading is preferred).
then compiling the whole application(preferebly by ant)
u will come to know all the dependencies.


saddysan

[dlorde]

I was recently part of an IDE evaluation team, and we looked at most of the Java IDEs currently available, with two objectives - a high quality Java editor for day-to-day use, that everyone could install (i.e. not too heavy on memory, not too expensive, but fully featured for daily work), and a high-end IDE for more specific, less frequent requirements, such as project design work, initial EJB development, analysis, etc.

One of the best all-singing all-dancing IDEs is Together ControlCentre (http://www.togethersoft.com/products/controlcenter/index.jsp) (now owned by Borland). It's also one of the most expensive. I find it too complex and unwieldy for everyday use, but it's good for UML round-trip engineering and EJB development. This came out as our IDE of choice for a high-end special requirements IDE - floating licences mean you can buy a few licences that people can share when they need the special features.

JBuilder (http://www.borland.com/jbuilder/) (also by Borland) is pretty good - I'm not mad on it, but some people love it. Depending on the version, it tends to be cheaper than Together CC.

IBM's Eclipse (http://www.eclipse.org/) open IDE framework with the Java plug-in is fairly popular, and is free, but because it relies on open-source plug-ins, the quality of various plug-in features is variable (from awesome to awful).

There are various other pretty good IDEs, but my favorite by far is IntelliJ IDEA (http://www.intellij.com/idea/). It is reasonably priced, and is the most intelligent and intuitive IDE I know. It doesn't have UML diagrams and round-trip engineering or a WYSIWYG GUI editor, but for plain Java, JSP and EJB coding, it's terrific. This topped the list for our everyday 'vanilla' IDE - by the time we finished our assesment, we were all using it!

One mans terrorist is another mans freedom fighter...