Java News from Thursday, August 24, 2006

Jeff Pace has released version 5.1.2 of DoctorJ, an LGPL'd Java application that analyzes Java source code in three areas:

It especially focuses on comparing API documentation to code. Version 5.1.2 is said to improve the detection of runtime exceptions (e.g. it no longer complains if you have an @throws comment for a runtime exception, but don't declare it in a throws clause) though I have yet to test this myself. Users will need to inlcude the relevant exception classes in their classpath if they're using custom runtime exceptions. Standard runtime exceptions like NullPointerException and IllegalArgumentException should be automatically detected though.

Google has posted the early draft review of JSR-284 Resource Consumption Management API to the Java Community Process. According to the JSR,

Software systems in many circumstances need awareness of their resource usage. Meeting performance requirements often requires the ability to manage consumption of resources provided by the environment. Resource management is traditionally handled by operating systems, but the growing need to use the Java platform in the systems programming domain adds increased pressure to equip it with resource management capabilities at a level of abstraction that fits gracefully with the language.

Preventing denial of service attacks, providing load balancing, and monitoring the usage of a given resource are all difficult to do in the current version of the Java platform. In general, these and other features cannot be provided without going beyond the Java language proper, through mechanisms such as native code or shell scripts that ask the OS to handle matters related to resource management. The lack of a standard, programmatic way to partition resources available to virtual machine(s) among Java applications has led to a number of ad-hoc solutions.

The Resource Management API for J2SE Applications should address the above and be characterized by the following:

Concrete examples are given below to demonstrate the need for and usefulness of the proposed specification. None of them can be realized by current APIs.

The API should enable resource management policies to be programmed. In particular, such a policy should have the ability to define when an application may gain access to, or consume, a unit of a specific resource. It should be possible to bind computations dynamically to policies. Programs should be able to reserve resources in advance and thus ensure predictable execution. Applications should be able to install resource monitoring code so that proactive programs can observe resource availability and take any actions required to ensure performance and availability or to ward off denial of service attacks. Existing applications should run without modification, even if the Java platform classes or the Java runtime environment they depend depend on exploits the resource management framework. The interface should not impact in any way how actual resource providers (schedulers, automatic memory subsystems, etc.) should be written - it should be possible to make these providers become "RM-enabled" by inserting calls to appropriate API methods to convey information about resource consumption attempts. The effort required to retrofit existing resource managers should thus be minimized.

The specification will build upon the abstraction of an isolate, as defined in JSR 121. An isolate is an encapsulated Java program or application component that shares no state with other isolates. Isolates are a convenient abstraction on which to develop resource management: isolation allows unambiguous resource usage accounting and clean reclamation upon program termination. The expert group will also look at enabling the API to operate on platforms that do not support the Isolate API. In particular, a single JVM could be viewed as a special case of a single isolate.

In addition to defining an API, which will be a framework through which resources can be uniformly exposed to client programs as entities subject to management, the outcome of this JSR will include a non-empty set of resources deemed core and required by compatible implementations.

Comments are due by September 22.