Anyhoo, inspired by the simplicity of the work that Leo has done with the attributes, and wondering what the most generic way to work with JAR files and still be productive, the answer came to me from the JMX specs for Advanced Dynamic ClassLoading. The specs as written take care of the hard stuff, which is a good starting point. If we combine this with the Attributes, then we should have a winning combination.
The basic crux of the solution is to have JAR files loaded into a repository. The classloading process follows the following logic:
1. If the class is not already loaded from this JAR, try to load it from the parent class loader. (same as always)
2. If the parent class loader can't find it, delegate to the repository.
3. The repository attempts to load the classes from each assembly (a classloader representing the individual JAR file), in order.
4. If the class is never found, throw a ClassNotFoundException. If the class is found, return it.
Pretty simple, huh?
There is an addendum to that in the current spec where the class repository will give up as soon as it encounters the requesting classloader. The reason is to avoid a potential deadlock in the classloader mechanism. The specs outline the precise conditions on which that would happen.
Now, this is a good start. There are several features not present that make sense when we start talking about a JAR repository. We are all fully aware of the implications of dependencies and how to sort a list of objects so that there are no circular dependencies and the most needed objects are at the head of the list.
Where is this information kept? Traditionally in the Manifest. Each JAR has its own manifest, which can be reused. To that end, we need to be able to load and parse the manifest file so that we can get all the attributes for the JAR. While we are at it, we can also grab a list of the entries found in META-INF/services. Both of these things can be done without altering the known specs or inordinately affecting startup time. If the library assembles the list of services, then we don't have to have a particular file named "services.list" that is part of the Fortress spec. Also, if the manifest information is made available generically we can support the Merlin way of doing things.
How does this sound?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
