JSRs: Java Specification Requests
JSR 143: JavaDesk
Reason: This JSR was not approved by the SE/EE Executive Committee in the JSR Approval Ballot.
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0
JavaDesk provides a standard desktop API across platforms using an MVC model. Applications can control and enhance the desktop using the JavaDesk API.
Please direct comments on this JSR to the Spec Lead(s)
This JSR has been Rejected
Section 1. Identification
Submitting Member: Bay Equities Inc.
Name of Contact Person: Jeremy Teeuwsen
E-Mail Address: email@example.com
Telephone Number: +1 780 430 0056
Fax Number: +1 780 437 6121
Specification Lead: Rich Isaac
E-Mail Address: firstname.lastname@example.org
Telephone Number: +1 780 951 2923
Fax Number: +1 780 437 6121
Initial Expert Group Membership:
Bay Equities Inc.
Section 2: Request
2.1 Please describe the proposed Specification:
The JavaDesk API specification provides common desktop services to all Java platforms. Hosts implementing this specification have the following benefits:
1. Is able to run on any Java capable devices. This will significantly simplify the task of administrating heterogeneous environments - from PDAs to workstations.
2. Is built using an MVC architecture. This architecture separates the components implementing the specifications into two distinct components: the Model/Controller and the View.
3. Provides access to all the processes executing on the host. Currently, the only processes available to a Java program are started by the Java application. Providing access to all host processes allows users and administrators better control of their environment.
4. Provides access to Frames(windows) open on a desktop. JavaDesk view employs this feature to handle context switching and control.
5. Manages desktop, network and user preferences including menu structures, favorite URL links, proxy servers, printers, and file servers.
6. Manages authentication and authorization of JavaDesk features.
7. Facilitates inter-process communication between JavaDesk and other processes.
8. Manages command mappings with various file types and MIME types.
9. Provides extensible features to the desktop through the use of Applets. For example: clock, security.
2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)
JavaDesk provides desktop services to all Java capable devices with a graphical user interface. This would include platforms ranging from PDA to workstations. Some features that JavaDesk provides are option due to platform limitations. The specification will expand upon platform capabilities and which features are available.
2.3 What need of the Java community will be addressed by the proposed specification?
JavaDesk satisfies the following needs:
2.4 Why isn't this need met by existing specifications?
Existing specifications do not provide desktop services.
2.5 Please give a short description of the underlying technology or technologies:
JavaDesk brings together a number of technologies to provide a more consistent user experience and API across OS platforms. These technologies include:
2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)
2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?
JavaDesk is dependent on a host with a graphical user interface. Although JavaDesk Model-Controller component can operate on a platform without a graphical user interface, it would have limited utility.
2.8 Are there any security issues that cannot be addressed by the current security model?
2.9 Are there any internationalization or localization issues?
Yes JavaDesk model will provide internationalization and localization information to the active JavaDesk view. Through the profile structure JavaDesk manages internationalization and localization options for a more consistent user experience across Java applications.
2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?
2.11 Please describe the anticipated schedule for the development of this specification.
2001-07-17 Submit JSR application.
2001-08-07 JSR approval by the EC committee.
2001-08-17 Expert group established.
2001-08-31 Draft of specification completed and approved by expert group.
2001-09-04 Submit Draft for community review.
2001-10-30 Draft revised by the community review and ready for review by EC.
2001-11-06 Submit draft for public review.
2002-01-04 Complete the final draft, the RI and the TCK.
2002-01-29 Submit the final draft.
2002-02-12 EC approval of final release.
2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.
Conference calls will be held roughly every 2 weeks, and a formal mailing list will be set up for more frequent communication. Members of the expert group can initiate additional conference calls to resolve issues.
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.
3.2 Explanation of how these items might be used as a starting point for the work.
Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.