Thinking: Dependency Injection and Runtime Geography (2)

A friend of mine responded and asked how I envisioned solving the problem of runtime geography. I don't have an answer yet. To me, identifying the 'true' problem is valuable because now I can search for solutions to the problem and know what I'm looking for, instead of just having a vague sense that something is wrong.

I don't think annotations are the right thing to do, because they are also compile-time entities. That might be somewhat helpful compared to the Java package/name hierarchy, but probably not by much. Instead, I think we need a way to categorize objects and group them at runtime. ThreadGroup is an example of doing this for threads, and that might be useful in some manner here (perhaps using annotations to instantiate thread(group)s which are marked differently). But that is focusing on the geography of the execution threads. I think we also need the means to map the geography of the objects and their state and references.

Annotations in 1.5 don't let you assign annotation values at runtime. That's essentially what we need. We need the means to annotate information on objects independently of their class at runtime.

I haven't found a means to do what I want yet. I'm looking for it. It may not be possible in Java as it exists today (though I'm going to keep looking in hopes of finding a means to do this). I am not a fan of Aspect-oriented programming, but AOP might provide a means to augment normal objects with this runtime capability.

Of course, there are two parts to the problem: (1) how to annotate objects in a manner that creates a runtime geography and (2) how to utilize that runtime geography to solve a particular problem, like dependency resolution.