How to find which of my classes depend upon the one I now want to change?

[Dunc Smith]

Hi
Elaborating on the title of this post:
- So far I have been quite content learning the ropes using Textpad as I prefer to have good visibility of the nuts and bolts of what I'm doing.
- I've written many classes that support a number of small applications, some more or less done, others still in progress.
- As far as I can, I have tried to write classes in such a way that allows me to expand them by adding methods so that their existing function isn't compromised.
- But every now and then I find that it would be much better to change parts of a class upon which other classes depend.
- Its at this point that I need to be sure that I can make a change knowing precisely which higher level (i.e. dependent) classes will be impacted.

I'm not working in a team and so I know that I have access to all dependent classes. What I would like is just to be able to point some tool at my development folder and then make a simple list of all of the source code classes that have a dependency on the single class I am considering changing.

It seems so simple I am tempted to write such a thing myself though I'm sure there must be some tools around for this. Having looked around on the web I only seem to find references to professional tools that do hundreds of more complicated bits of analysis and would take a month to learn. Even Oracle's website is pretty poor at identifying a beginner's introduction to how to use JavaDoc. So far I have stayed away from using one of the popular IDEs (can they help with this problem?) as my limited experience is that they try to force the developer to keep things ordered in a manner that suits the IDE rather than the developer and don't seem to offer much migration support for projects that are already underway, though I'd give one a try if I had a good steer.

So, does anyone have any suggestions for a starting point, with the emphasis on finding a simple tool that does a simple, limited task?

Thanks
Duncan

[Matthew Brown]

A modern IDE will do this for you. They've got built-in functions to find all references to something (class, method, variable, whatever), and to do refactoring like renaming classes and methods consistently across the application. And lots of other useful stuff.

With Java, the IDEs don't force you to act in a particular way much either, especially if you don't use the GUI builders. The folder structure is already mandated from the way Java works, and the rest is all Java source files. For straight-forward applications it's actually very easy to switch from one IDE to another.

It's good to learn Java in the first place the way you have, as you don't have to try and learn the tool and language at the same time and you end up with a better understanding. But once you're past the initial stages it's definitely worth making the shift.

[Dunc Smith]

Ok thanks.
I suppose my reticence with IDEs comes from the ones I have tried and just found too bureaucratic to want to progress with, though I have been wondering about going back to either Eclipse or trying Netbeans. Your thoughts are interesting, makes me wonder if I'm not looking at the problem the right way.

I think you are saying I could either in such a way that I can keep my source files and where I want, letting javac put the class files in the mandated structure and, more importantly, not have the IDE impose some kind of structure where I have to say which files are part of a project before it will even blink at them and then leave project files and other fragments scattered around, (hmmm, I've noticed I'm venting previous irritations with IDEs!).

More seriously, I'd like to be able to write an application by working out a class concept with pencil and paper and then build up the utility classes as standalone utilities that I can unit test before pulling things together.

[Campbell Ritchie]

That sounds a good idea. You can of course create and test utility classes on their own, since they usually only have static members.