If we think about locating things on a map, there are numerous types of things, and their locations can be specified in a variety of ways. For example, we have towns and cities, which have a name (not always unique) and occupy a particular area centered on a point that we can specify with a longitude and lattitude. We can also talk about things in a relative manner ("Chicago is about 350 miles north-northeast of St. Louis). We sometimes want to find things based upon nearness (Where's the nearest pizza place that delivers?). We can also talk about roads, rivers, right-of-ways, etc., all which follow a route (which is usually specified by a width and a series of points specifying its path).
So, if we're going to have a runtime geography for the objects in the VM, we have to solve several problems and answer a number of questions:
- What are the various dimensions used to create the space? Anything that might be a dimension must be something for which we can directly assign a value to an object, or one for which we can derive a value for an object based upon some affiliated/associated object.
- How do we make the geography available to Java code? Once we've come up with some definition of the runtime location of objects, we need to be able to assign a location to an object and we then need to be able to specify a location or region to locate one or more objects.
- How do we avoid conflicts with other ways of organizing objects in the VM? There are at least two ways to define a 'location' for an object at runtime today: the ClassLoader that loaded it's class and the package it is defined in. We might be tempted to include the Thread(Group} which is executing code of this object, but this has the problem that (a) it is transient and (b) it can result in multiple locations for the same object. We should leverage these if possible or at least not clash with them.
- How does our solution fit into a distributed system? There are many situations where multiple Java VMs communicate with each other. Should the runtime geography be a purely internal thing which is never exposed outside a VM, or should we expose it and use it across VMs?
To make the whole discussion concrete, I'm going to focus on two particular uses of a runtime geography that are fairly different from each other. While I hope a well-conceived runtime geography will be applied to many problems, these two seem like a good start:
- Dependency injection at object construction time - finding objects required by the constructed object based upon where in the program the object is created
- Location-dependant logging - specifying different logging levels for the same kind of object used in different locations in the program. For example, assume StringTokenizer produced logging messages for your favorite logging API. If a JDBC driver and some user-written piece of code in the same program use a StringTokenizer and you want to crank up the logging messages for StringTokenizers 'inside' the JDBC driver but not 'inside' the rest of the program, how can we use runtime geography to do this? What if we want to crank up all logging inside the JDBC driver?
In addition, we should meet some design goals:
This feels like enough to start mashing ideas together. Now it's time to do the serious thinking... :-)