Oxygen will not use manifest files to declare dependency information between components. This idea is flawed - Java is an inherently late bound, and flexible language. Problems arise (particularly when systems like serialization are used) to define a fixed set of classes (or packages) that a component will be required to load in its life. As new classes and packages can be introduced after the class was built - and these can still operate through the interface known to the original class - provided that interface changes only in a "compatible" way.
Oxygen will not use objects to represent a handle to services, and oxygen will not track service use. Systems like OSGi do this - requiring clients to specifically (with lots of repeated code) acquire and release handles to service objects. Also references obtained are to some object that must be further de-referenced. Oxygen will operate with simple, conventional service references. OSGi uses this model for two reasons: to encourage good housekeeping in service consumers "tidying up references" at the end of their lifecycle. And secondly as a mechanism to control services being unregistered.
Service consumers need not be components - any Java code can acquire a reference to the service manager