<i>You can't ask this question because you can't not already know the answer.</i><p>This isn't true.  Here's a trivial scenario for you: a user inputs a URL which represents a web service and a method name.  Your code needs to determine if the object which will get returned as JSON by that web service implements the method or not.<p>There are more complicated examples which occur in actual production systems.  For example, suppose you're interfacing with Big Freaking Enterprise code that you can't change, and there is a rule that certain objects have to have certain checks done prior to being sent over the wire.  Those checks might be implemented as methods decorated with @FireThisCheckBeforeSendingThisOverTheWire annotations, but that isn't the only way to skin this particular cat.  In particular, your million lines of legacy code might have a coding convention where any method starting with "check" gets fired.  This worked fine when the code was only running in its own little world and teams of overpaid engineers maintained lists of all the check methods for various classes, but now that code needs to get exposed via a new API to meet some emergent business need, and you want to accomplish this without touching the million line codebase that nobody really understands.  Enter the reflection API.<p>Incidentally, expecting a coding convention like that to actually work isn't totally insane.  JUnit 3, I think, treated any method starting with test as a test.  I personally prefer it for usability over "slap an annotation on it".<p>Anyhow, Enterprise Java: abandon all hope ye who enter here.