a more general solution

The idea of having a wrapper object worked great for int, long, String, boolean, byte array and serializable objects. This is because all of these have only Object get() and void set(Object value) methods. But using a wrapper is not generalizable.

Basically we want to have two objects, an application object and a peer object, where the application object is only required to implement a simple interface and the peer can be subclassed (e.g. in COODBMS). That is a solution which will work for every case, but it is a big change. And with all the code we've got, it would be best if that change could be implemented piecemeal.

So we can begin by supporting the peer object--which looks like a wrapper to the internal code--with additional support in PContainer for the App getApp(key) method. It will be a bit of work, but should be worth it.

This approach also solves another problem--the interfaces exposed in the API is far too complex. All that complexity now moves into the peer and the only method left exposed in the API is the Peer getPeer() method. So we get to kill two birds with one stone.