Trying the obvious
Especially Jini developers often have to wrestle with ClassNotFoundExceptions due to incorrect codebases or classloaders that are associated with the wrong codebase.
The codehost project tries to tacle these problems by removing the codebase URLs. This may seem strange first. How do you download the classes you need without any information where to get them from? But does removing the codebase really remove all information about where to obtain a class from? The codehost project profits from the side effect of a naming convention that is used in most Java projects and is even suggested by the Java Language Specification.
Java projects are contained in packages that are prefixed by a reversed internet domain name. E.g. Sun releases its classes in packages that are all prefixed by 'com.sun', derived from their domain name 'sun.com'. When a class needs to be loaded, the codehost system simply reversed this process and uses the resulting domain name to contact a server on that domain name to download the class.
Of course the whole system is more complex, and a number of optimizations are employed to make the system performant. But the initial release showed that it can principally work and will serve as the basis for future work (e.g. to transmit the metadata that is currently contained in the META-INF directory of Jar files).
Everyone interested in the approach please visit the project homepage at http://codehost.jini.org/ to find out more.