Samsung has submitted JSR 278, Resource Management Framework, to the Java Community Process. According to the JSR,
Traditionally, Java platforms that run in a single operating system process do not provide explicit management of resources since it is taken care of by the operating system?s intrinsic features. The only resource management facility provided by the virtual machine is the Garbage Collector which is solely responsible of managing memory for all Java objects (regardless of which application they belong to) within a virtual machine. The main limitation of the garbage collector is its inability to handle native resources such as files, sockets, and native memory allocated by JNI native methods. Furthermore, reachability of Java objects may not be sufficient for determining whether an object is indeed "alive" or not, since an object may be reachable through a shared collection of objects (or repository) and yet be bound to a particular application whose lifecycle determines the liveness of the object.
However, several containment frameworks such as Xlet engines typically run in a single virtual machine within a single operating system process and provide an environment that can initiate, run, and terminate multiple applications. When these containment frameworks are embedded in systems requiring high availability, they necessitate explicit management of resources in order to provide a robust and long running environment.
The core of this API is an interface called ResourceManager which defines an interface that all resource managers must provide. The functionality provided by ResourceManager is the ability to force the reclamation of all resources bound to a specific application execution environment. Also, resource managers (classes implementing the ResourceManager interface) may be dynamically added to the framework. This provides extensibility which allows new profiles to be added to the Java platform and still benefit from the integrated resource management framework.
The extensibility feature of this API is the most important factor for proposing this API in the standard JCP process. Any existing or newly profiles that utilizes this API will benefit from its functionality and reversely, any Java platform that supports this API will be able to provide robustness as long as any plug-in profiles support this API.
This API assumes (or may include) the definition of application execution environment, which provides a unique isolated computing environment within a virtual machine that is particular to each application. The Application Isolation API Specification (JSR-121) is particularly well-fit to serve this purpose. It clearly states that resource control is not within its scope.
This API particularly targets J2ME platforms that run in a single process environment. Hence, multi-process virtual machines (mostly in J2SE or J2EE platforms and even in some J2ME platforms) may not benefit from providing this API.
Resource Management Framework (RMF) API will be an optional package for the J2ME configurations CDC. This framework will focus on the ability to control the usage of resources among different applications within a single Java Virtual Machine. RMF will have a resource manager for each resource such as file, thread, socket, image, etc. These resource managers will be kept alive as long as the Java VM is running. All the resources which are bound to a specific application execution environment will be freed by the resource managers upon termination of the environment. The resource managers should be bookkeeping all the resources. The unit of management for the RMF API is an application execution environment. The abstraction introduced by the Application Isolation API (JSR 121) best serves this feature.
Comments are due by July 11.