• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Java Technologies for programmatically finding usages of methods

 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is anyone aware of a projects out there that can answer the following question? I'm basically looking for a programmatic "find usages" library, similar to what IDEA or Eclipse can accomplish.
Here is an example:

- Given a change in method X, is method Z potentially impacted?

So here is an example where the answer is: Yes






Here is an example where the answer is: No





 
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry, I'm not really aware of any such tool. I really wonder why such a tool would be useful though.

You should program against an interface, and unit test your methods. When a change occurs that breaks the contract, your tests should start ringing bells. Otherwise, the change had no effect on the outside world (except maybe for performance), and then there's also no need to trace the usage.
 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:Otherwise, the change had no effect on the outside world (except maybe for performance), and then there's also no need to trace the usage.


Totally agree, and I'd actually go further and say that the need for such a utility suggests that your design is too tightly coupled. Personally, I dislike methods that have a return type of void, because they smack of mutators (although sometimes, as with main(), it's unavoidable), so if I was going through an exercise like this, they're the ones I'd pay closest attention to.

Winston
 
Stephan van Hulst
Saloon Keeper
Posts: 15510
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It also just occurred to me that this is nearly impossible to do at compile time, because of polymorphism. If you call x() from y(), which class' x() are you really invoking?
 
Cristopher Stauffer
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think it is both valuable and possible within a well designed system.

Let's say for example that there is a QA process at a factory, one in which widgets that "pass" testing have a sticker with the factory id, floor number, and QA engineer id number. If a product escapes into the market with a bug, and is defective, the QA engineer id number, along with other numbers, can trace it to the factory, floor, and engineer that "approved" it. In your proposal I think you are saying that traceability is of no value beyond an interface (i.e why would you ever care how something got screwed up, you just care that it is screwed up). I think the spirit of that principle sounds good, but doesn't hold true in even the most basic real-world scenario.

Translating my example to a software project:

Let's say for example a bug is introduced (despite your hardest attempts at unit test coverage) in which a method on a service interface is now misbehaving (as reported from a consumer of this interface), and you now have a production bug against a service interface. Such a tool might be able to look at the recently deployed change sets and tell you which change sets "may" have impacted that specific method.

With regards to polymorphism, I'm more interested in an approach that tells you there "may" be a connection between the two. Certainty is never guaranteed.
 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hope we are not too late, but


Welcome to the Ranch
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Cristopher Stauffer wrote:I think it is both valuable and possible within a well designed system.
Let's say for example that there is a QA process at a factory, one in which widgets that "pass" testing


Sorry if this sounds pedantic, but what you're describing is not QA (which stands for Quality Assurance) but QC (Quality Control). Indeed, QA came about specifically because of the (relative) failure of QC-based systems; and several programming methodologies (XP and TDD spring immediately to mind, but there are many others) are specifically designed to mitigate the write→test→deploy cycle.

What you want to do is prevent errors, not filter them out; and an execution-path checker says to me that you've resigned yourself to the fact that you've failed in that goal.

Which is not to say that refactoring tools aren't useful, but I've not really found a need for anything more than the ones which come with most IDEs.

Winston
reply
    Bookmark Topic Watch Topic
  • New Topic