Section 2: Request

2.1 Please describe the proposed Specification:

The Java platform has currently no suitable tools for developing and deploying independently running services like UNIX daemons in a uniform cross-platform fashion. System level services, however, are an essential need on each server platform. Developers are left alone when the question arises, how to install Java services on a given platform. This dilemma is caused by differences in handling system level services on the individual platforms, e.g. Unix versa NT. In addition, some platforms, e.g. Windows 95, are completely missing such functionality.

The Java daemon framework should fill this gap. The proposal consists of interfaces and classes for developing and deploying independently running services using the Java language and tools, only. In addition, the framework contains an SPI for providing suitable containers in order to host Java daemons.

Daemon containers may be supplied on both, the Java platform and native platforms.
A simple command line tool should be included in future JDK releases for deploying and managing Java daemons on each platform in a uniform fashion. Third party vendors may supply more sophisticated tools for deploying, hosting, watching and controlling life cycles of Java daemons.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Daemons are required on arbitrary platforms. The server platform would, however, be the typical target environment.

2.3 What need of the Java community will be addressed by the proposed specification?

The Java community would obtain tools for developing and deploying any kind of platform-independent services without having to integrate the Java application launcher with platform-specific handling routines, e.g. using native scripting and/or other wrapping techniques.

2.4 Why isn't this need met by existing specifications?

Using the current JDK, developers are still forced to deal with platform-dependent interfaces and deployment facilities if they want to establish simple services beyond high-level application container frameworks like EJB.

2.5 Please give a short description of the underlying technology or technologies:

The framework would consist of a common notion of system level services available on each platform. Native platforms, which are completely missing a notion of service, would be equipped with a maximum functionality available on the basis of the tools proposed for hosting Java daemons.

The Java daemon framework would supply classes, interfaces and command line tools

• for managing daemon context, i.e. runtime parameters,
• for controlling a daemon's life cycle, i.e. start, stop, restart functionality,
• for watching daemon state, i.e. listener functionality,
• for supplying daemon logging functionality,
• for deploying daemons using a simple command line style,
• for developing containers including native ones on the basis of JNI adapter classes.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

• java.daemon for the core classes and interfaces,
• java daemon.pausable for extended classes and interfaces,
• java.daemon.logging for logging functionality

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No.

2.8 Are there any security issues that cannot be addressed by the current security model?

No.

2.9 Are there any internationalization or localization issues?

Existing standard Java internationalization APIs will be sufficient.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No. Current Java tools, however, e.g. rmid may benefit from the new API and could be re-designed for also running as Java daemons.

2.11 Please describe the anticipated schedule for the development of this specification.

Initiation: November 2000.
Community Review: May 2001
Public Review: August 2001
Final Draft Proposal: November 2001

Further schedule will depend on the review process.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

A first document containing specifications and source code fragments is attached to the JSR as a PDF file. The complete source code is attached to the JSR as a zip archive.

3.2 Explanation of how these items might be used as a starting point for the work.

The document attached shows a first structural notion of Java daemons. The compiled sources can already be used for implementing samples. This starting point might encourage participants to join the expert group. In addition, the sources form a fully functioning preliminary RI for the NT platform. A Unix RI would result from an analogous mapping of the proposed interfaces to the semantics of rc init scripts.