 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 288: Adaptive JavaTM ME System API
Reason: This JSR was not approved by the ME Executive Committee in the JSR Approval Ballot and JSR Reconsideration Ballot. JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: This specification will define a mechanism that enables a systems developer to include multiple Configurations and Profiles on a single device, using one set of developed components. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Rejected The following updates have been made to the original request.
2006.02.07 Initial Expert Group Membership: Aplix Supporting this JSR: Aplix Section 2: Request
2.1 Please describe the proposed Specification:The Java ME environment used by existing mobile devices is produced in a fixed fashion and is typically configured at time of manufacture for a single field of use. A single field of use means that only one pre-defined Java ME execution environment is available on the device. There is growing interest in the wireless Java community to extend the life of existing hardware (e.g. mobile phones) and services. Additionally, there is interest in supporting multiple Java ME execution environments on a single device. Multiple configurations and profiles have been developed in the Java ME market and are shipping in products around the world. Hardware resources, operator specific requirements and overall market trends are some of the factors that help determine which Java ME environment that a manufacturer adopts. We envision that this specification will enable a manufacturer to include multiple Java ME execution environments on a device. Implementing this specification will enable manufacturers to create intelligent devices that are capable of determining which Java ME execution environment to use based on the needs of the application that will be launched. By using this JSR, a system developer will be able to configure a Java ME system out of a given set of verified and tested static system components, like the components that build a JTWI compliant device. These components are based on pre-specified, stable, Java ME execution environments. For example, CLDC, CDC and MIDP3 are all components. This JSR would enable a system developer to build a device that supports both MIDP3 on CLDC and MIDP3 on CDC. This JSR will be helpful to system developers who assemble Java ME environments and 3rd party developers who deliver interoperable components for integration to system developers. Java application developers will not have access to JSR 288. They cannot code to the API. It is therefore invisible to the application developer. The benefits of JSR 288 to the application developer include under special permissions configuration of an execution environment in debug, log and scheduling modes as well as performance throttling and monitoring. JSR 288 can also allow for the inclusion of development or experiment environments. Device manufactures will gain the benefits of faster time to market, smaller footprints, and the modular design will allow component shopping. Network operators and service providers will gain along with the benefits of better developer support the ability to control platform access for higher protection of their service enablers. From a testing point of view, the pre-defined stable environments will be TCKed as stand alone execution environments using the currently existing TCK tests. To enable future J2ME platforms to become adaptive on a modularized level, this JSR will also need to standardize the design of the modularized TCKs to attain interoperability. Existing JSRs may enable their adaptive TCK through a maintenance release. This work can only be done within the Java Community Process (JCP), as TCKs form the basis of verifying any Java Specification and are standardized within the JCP. In order to allow the composition of system software components, meta data concerning TCKs performed and for which valid usable scenario they passed, an interoperable set of meta data for TCKs will be defined. As this is not an ad-hoc system, no untested unverified stack or component will be able to be executed for a Java application. Another concern of the system is security. This specification defines a system level API. From a security point of view this specification is concerned with system level security (e.g. the security/integrity between the system software components and interfaces). Consequently, this specification enhances the security in the system layer of Java Native Interfaces (JNI/KNI). In summary, the purpose of this JSR is to provide a system level API for configuring multiple Java ME platforms for a given hardware target. System developers need a way to create modularized system software components using an interoperable standard. This standard should allow these developers to generate verified and TCKed Java ME software stacks. Benefits to system developers include the ability to optimize footprints, lower the cycles of redundant tests, facilitate modular debugging and allow better 3rd party integration of system software. This will allow system developers to offer better deployment options to manufacturers and service providers and will reduce the time to market for Java ME based platforms versus other competing platforms. We believe this JSR will significantly help in this effort and it should become an industry standard. Without an organizing standard, the Java ME industry cannot independently verify the correctness and security of a multi-Java ME device. Previous implementations have been successful at creating devices that support multiple configurations and profiles, but lacking a standard there is no way to independently test that a device behaves within the bounds of a given specification. Since we believe that there is significant interest in developing multi-Java ME devices, we believe that there must be a way for the industry to test those devices so that faulty implementations do not undermine the fundamental pillars of the Java specification. This JSR will not require, depend, or define special Java ME Configurations or Profiles but instead will transparently support the ones that already exist. 2.5 What need of the Java community will be addressed by the proposed specification?JSR 288 will provide an efficient way to meet the industry goal of a multi-execution environment Java platform. For example, creation of a single device supporting 1) a legacy CLDC environment 2) a MIDP 3.0 CLDC environment and 3) a MIDP 3.0 JSR 232 CDC environment, where the components of each environment are reusable. If a standard approach is not defined at the system level there are many behavioral inconsistencies that could result in further fragmentation of the Java ME platform. This fragmentation would result in the need for stronger, smarter, and more costly management infrastructure and will result in unnecessary communication and bandwidth consumption. Individual JSRs that can benefit by JSR 288 are discussed in the following paragraphs: JSR 248/249 create mobile service architectures and platform definitions for the J2ME space. JSR 288 can host the essential components referenced and defined within these JSRs in order to allow the matching of the correct use of JSR 248/249 in a flexible way. 288 can configure a strict environment of mandatory or a more relaxed environment with mandatory and optional components agnostic to the deployed application. JSR 246 interprets and handles the OMA DM protocol whereas this JSR does not have any protocol elements associated with it. Upcoming OMA Device Management Specifications may be handled by an implementation of JSR 246 and JSR 288 together in order to fulfill the OMA specified management objects within the Java ME space. In this case JSR 288 is used as supporting technology for some OMA Management Standards. JSR 232 provides functionality at the application and service level as part of the execution environment; JSR 288 is not visible at that level. Additionally the DMTree can be used as dictionary storage for JSR 288 that is up to the system developer, showing an efficiency of development when building both systems together. JSR 288 leaves open an SPI (System Provider Interface) to resource managers like JSR 278. If an implementation of 278 is available for the target system, JSR 278 should be the implementation of choice to fulfill that SPI. The SPI allows the easy integration of Repository APIs. It also allows JSR 288 to work with the elements of the repository in an independent way and therefore generate virtual resources for the dictionary without the need to specify them in detail. In addition to the SPI, JSR 288 also provides a routing/bridging function for resources in order to substitute / combine physical resources for a target Java ME configuration. As an example, if HTTP over TCP/IP utilizing CSD is not available in the network, HTTP over TCP/IP utilizing USSD can alternatively be configured and activated on the fly. 2.6 Why isn't this need met by existing specifications?The configuration API is unique to JSR 288 and no other JSR in Java ME includes anything similar. JSR 246 and JSR 232 provide functionality of management for applications, but they focus at the protocol and application level. JSR 288 is a system level configuration API, which complements the above mentioned JSRs and will help system developers provide pre-defined and thoroughly tested multi-execution environment platforms in a flexible and cost effective manner. It is intended to work closely with JSRs like JSR 246, JSR 232, JSR 271 and, JSR 278 so that they can benefit from JSR 288. 2.7 Please give a short description of the underlying technology or technologies:Individual components needed to assemble a predefined Java ME platform will be identified and registered in a dictionary with all vital information about the component for usage by the system developer. Communication between the Java ME environment (e.g. the AMS) and the application description/manifest will result in the information needed to determine the required Java ME system configuration. At runtime the VM starts JSR 288 which then selects the appropriate registered verified system components for the targeted Java ME environment out of the dictionary, and continues to assemble the environment. Once the Java ME environment is started, the configuration layer of this specification will not be accessible by the application and the configured Java ME environment cannot be changed in any way. The application only sees its requested Java ME software stack. The configuration API will only deploy required system components and will not expose any other system components that may reside within the dictionary. The API will have the following functionality: Add, remove, save and reload functions for the dictionary. In addition a verify function is available to verify the consistency of the dictionary. Functionality like encryption will not be necessary, as the dictionary implementation is private and not standardized. Therefore, a licensee?s open classes can be hidden from application developers who have no rights to utilize them. Currently they are part of any deployed Java ME stack and allow application developers to build software that does not conform to other Java ME environments, which ultimately leads to fragmentation. Implementing this specification will prevent such scenarios and would only allow access to additional, nonstandard classes if the originator of those classes grants the developer the rights to do so. As this JSR is only available in system mode and not accessible to applications, Java ME applications cannot inherit security mechanisms other than the ones deployed with the configured stable pre-defined Java ME stack requested. Basically this JSR operates on system level security and firewalls all assembled Java ME environments. The granularity of protection is implementation dependent and will not be specified, but a system level security guideline for system developers will be added to the specification. Testing this environment will require exactly the same tests as provided by the required TCK tests. Only difference is that the tests can be modularized and need only to be reapplied if and only if the system software component changes, in which case the dictionary will reveal the need of the test. This allows for focal tests and stress tests on individual components that may require so. Given the modularity, groups of system developers can specialize more on sets of system components and need not to investigate complex Java ME stacks. 2.13 Please describe the anticipated schedule for the development of this specification.February 2006: EG formed. 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.These terms only represent the initial commercial terms to be used and remain subject to the execution of final legal agreements covering the subject matter hereof to be determined by Aplix at its sole discretion. We will license to all interested parties. Independent implementations will be allowed - TCK and RI will be licensed separately. Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Aplix Corporation Name of Contact Person: John Rizzo E-Mail Address: john Telephone Number: +1 415 233 2610 Fax Number: +1 415 558 8822 Specification Lead: Andre Kruetzfeldt E-Mail Address: andre Telephone Number: +1 415 558 8800 Fax Number: +1 415 558 8822 Initial Expert Group Membership: NOTE that this information has been updated for the JSR reconsideration ballot.Aplix Supporting this JSR: NOTE that this information has been updated for the JSR reconsideration ballot.Aplix Section 2: Request
2.1 Please describe the proposed Specification:NOTE that this information has been updated for the JSR reconsideration ballot. The Java ME environment used by existing mobile devices is produced in a fixed fashion and is typically configured for a limited field of use. In order to allow the Java ME platform to support a wider field of use, a mobile device currently must be reflashed. Multiple configurations and profiles have been developed in the Java ME market and are shipping in products around the world. Hardware resources, operator specific requirements and overall market trends are some of the factors that help determine which Java environment (Java ME configuration + profile) an application developer adopts. This specification will define a mechanism that enables a systems developer to include multiple Configurations and Profiles on a single device, using one set of developed components. An implementation of this specification will enable devices to adapt to the appropriate Java ME Configuration Profile (and optional components) based on the type of application that is being deployed (i.e., what Java APIs are required). The primary benefit of this specification is that it enables for flexible field deployments of J2ME platforms. This specification will not eliminate the need to reflash the mobile device in the case that core Java ME platform functionality was not initially deployed and TCKed. The systems developer will be able to pass all mandatory TCKs for initially deployed Java ME components. At the same time, the systems developer can enable initially deployed Java ME components for which the appropriate TCK has been passed to be adaptive and compliant without having to rebuild the entire code base or perform specialized source code builds to generate the desired Java ME platform for the target system. Utilizing this JSR, the systems developer can gain a smaller deployment footprint in compliance to the required TCKs. Additionally this JSR will provide a methodology to handle the scenario where a Java application attempts to launch, but the underlying functionality required is not implemented or not available. This kind of scenario currently causes a failure to occur in the Java application. For the application developer, the Java ME stack will be automatically constructed in a way that the chances of such failures are dramatically reduced. In the case that the application is not suitable for the deployed Java ME system deployed, the mismatch of the Java ME platform is reported back to the application and the application developer may then enable the application to provide the additional functionality or terminate gracefully. This JSR will also specify clearly defined recommended practices regarding security and deterministic behavior for such adaptive Java ME environments, in order to increase the level of software confidence. This JSR will not require, depend on or define special Java ME Configurations or Profiles but instead will transparently support the ones that are already available. NOTE that this information has been updated for the JSR reconsideration ballot. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Java ME 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.This JSR is submitted to the Java ME EC. 2.4 Should this JSR be voted on by both Executive Committees?No 2.5 What need of the Java community will be addressed by the proposed specification?NOTE that this information has been updated for the JSR reconsideration ballot. Currently an adaptive software configuration for Java ME environments and the capability to address such a system is not available to the Java community, as security and behavior are not defined. 2.6 Why isn't this need met by existing specifications?NOTE that this information has been updated for the JSR reconsideration ballot. A configuration mechanism for Java ME is not defined by other JSRs. Currently a single complete Java ME system, (i.e., Java VM and base classes) must be readily installed, configured and available (commonly known as Java ME Configurations) with fixed Profiles available. The usage of adaptive software configurations and their behaviors are not currently defined. 2.7 Please give a short description of the underlying technology or technologies:NOTE that this information has been updated for the JSR reconsideration ballot. This JSR is expected to define four major components:
2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.configuration 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.10 Are there any security issues that cannot be addressed by the current security model?No 2.11 Are there any internationalization or localization issues?No 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.13 Please describe the anticipated schedule for the development of this specification.NOTE that this information has been updated for the JSR reconsideration ballot. December 2005: EG formed. 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.E-mail and weekly phone meetings, face-to-face meetings as needed. 2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.Updates will be sent to the interest list that will be set up for this JSR. The list will be archived and the members will be able to post questions to the EG. 2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.Both the RI and the TCK will be delivered stand-alone. 2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).N/A 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.NOTE that this information has been updated for the JSR reconsideration ballot. The Specification will be made available at no charge. The RI for this JSR will be made available in binary form at no charge. The TCK for this JSR will be made available for a one-time flat fee of $50K with an annual $20K maintenance fee. In addition, qualified individuals and not for profit organizations will receive access to the TCK at no charge. 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.This subject has not been discussed in the community. 3.2 Explanation of how these items might be used as a starting point for the work.N/A |
|||||||||||||||||||||||||||||||||||||||||
