Coinjema Features

Coinjema needs to be able to merge dependencies in addition to simply overriding them. For instance, if context A has a property file, and context A/B also has that same property file, then objects created in context A/B get the properties defined in the A/B property file. It overrides the property file from A completely. Often that's what you want for most dependencies, but property files are a special beast, and I've found I usually want all the properties from A plus the properties from A/B - ie I want the property files merged, with specific properties from A/B to overwrite just the specific properties from A.

I also need it to be able to resolve all kinds of circular dependencies. Right now it does a good job of resolving most, but if you mix dynamic dependencies with static, you can run into trouble. You can also run into trouble if you access a shared dependency from a groovy script file using registry.getSharedDep(), because this also goes outside the "safe" flow of dependency resolution. I've looked at this and it appears to be an extremely thorny problem. If Java supported continuations, it's possible I could solve it that way. Of course, it that's true, then there's a way to solve it, I just have to implement my own continuations.

I'm going to need lifecycle control eventually. Doing initialization in the final dependency injection is just not good - causes too many problems. There needs to be a way to re-enter a routine to check for lifecycle needs after dependencies have been set and after the object is fully created, but before it is returned to the caller. Another tough problem. It means coinjema will have to keep track of all the objects it configured in any particular stack, and then go back through them and check for lifecycle needs.

What a Jini Needs

The Java Browser will not be a web browser written in Java. It will browse a peer-to-peer network of mobile java code and data. It will work like a normal web browser, except that instead of hopping from web page to web page via hyperlinks, users will hop from rich gui app to rich gui app via menus and buttons and commands. It will be the undesktop app, with all the power and flexibility of apps that fully live on your desktop, with all the ease and connectedness of thin-client apps.

To work, several things need to be made possible:

1. Transparent download and installation of the JRE. One will have to do an initial download and install of the application and a JRE (perhaps with Webstart's help), but thereafter, keeping up-to-date with the latest JRE should happen automatically. The JRE should be bundled with the app and should be independent of whatever system JRE might be installed elsewhere.


2. The main container application will be a jini browser that can get proxies from jini services. It will provide a sandbox for jini proxies to run in. The jini proxies will be entrance points to rich apps.


3. Jar dependencies should be tracked per app (per jini proxy) and cached on individuals machines for frequently used applications. Mobile apps will have to have some way of declaring their dependencies (jars and versions) and the container will have to have some means of finding and downloading (automatically of course) those third-party jars.


4. Will need custom class loaders to handle the dependency issues to allow multiple code bases to use differing versions of third-party libs.


5. Mobile code will have to declare their dependencies - not just libs, but JRE dependencies


6. The container will have to require that all downloaded mobile code be signed.


7. Security will have to be set up to disallow use of system resources unless the user allows it, and disallow net connections to multiple external ips, unless the user allows it. Preferably, these permissions can be bundled into a few simple-to-understand settings that allow users to grant permissions easily to the apps they like to use.


8. Would be nice if the container could require that any downloaded code is either open source and comes with the source for inspection, or licensed, such that the creator of the mobile code has bought and paid for a license to use the jini web.