ISO/IEC JTC 1/SC22/Java SG
ISO/IEC JTC 1/SC22/Java SG N 3-6
DOC TYPE: HTML Text
TITLE: ISO Java Standardization Profile
SOURCE: Japan's Expert Contribution
STATUS: This document is circulated to National Bodies of JTC 1/SC22/Java SG for review and consideration at the October 1998 SC22/Java SG meeting in Tokyo.
ACTION ID: FYI
DISTRIBUTION: P and L Members
NO. OF PAGES:
Text of contribution:
The following items are proposed in this expert contribution:
Java may be used in various fields of Information Technology, whose application range is from large-scale server systems to tiny embedded systems. Some systems should have strict interoperability based on "Write Once Run Anywhere". Virtual Machine concept is very useful for such interoperability issues. On the other hand, there are some systems which have their own specific requirements, and some optimization, such as native compilation, static linking, graphic functionality and memory size restriction, may be necessary for satisfying the requirements; server systems would have high performance in order to support a lot of transaction processing with accessing the existing database, client terminals would have a functionality for display of characters and/or images on CRT, and embedded systems would be restricted by available memories. In order to satisfy such various requirements, more loose interoperability should be allowed. Only one standard is not sufficient. Concept of profiling is necessary, which allows Java users to select an appropriate profile.
The proposal is based on the following assumption:
This proposal distinguishes between SMI Java and ISO Java. This is because any meaningless confusion is avoided which may be caused by no SMI's clear profile concepts and because the proposal is compared with SMI Java.
Hereafter, our Java is called as ISO Java, or its abbreviation ISOJ. Note that ISOJ is only used in this contribution temporarily.
Language Specification, Virtual Machine and API for ISOJ are called IJLS, IJVM and IJAPI respectively. Note that IJAPI includes Core and Extended APIs.
ISOJ has the following two different series of options:
The ISOJ profiling scheme is composed of level and category.
The details of level and category are defined in 2.3.2 and 2.3.3 respectively, and a taxonomy of ISOJ profile is specified in 2.3.4.
Level consists of the following 4 stages:
Note that IJAPI should include Core API, but that it may include some Extended APIs if necessary. The selection of Extended APIs may depend on a category.
An implementation which claims that it has a specific level in a category should conform to the level requirements in the category. This means that each category may specify its own set of mandatory/optional elements for the level, but that any implementation in the category should include mandatory elements specified in the level.
In this proposal, the details of category is not defined, but just the outline is described.
ISOJ must have interoperability to SMI Java in some ways. Level 3 provides a chance, but some alignment with SMI Java is necessary for the chance to have reality. From the point of this view, category should have the following 4 elements at least:
Other categories may be defined with a set of the definite mandatory/optional elements. Realtime may be a candidate.
The taxonomy of ISOJ profiles is described as a matrix by level and category.
|Level/Category||Level 1||Level 2-V||Level 2-A||Level 3|
Reference category is a base standard. A cell in other categories includes a conforming subset of the functions defined in the cell of the corresponding Reference category, which is a profile. Some category-specific functions may be added with the definite declaration.
"JDK", "Personal Java", "Embedded Java" and "Java Card" are equivalent to the current SMI's correspondents respectively.
Blanks in the above matrix will have some profile or be not available, which depends on each category. In each category, however, inclusion of Level 1 is mandatory and Level 3 should be compatible with SMI Java.
Another level and category may be possible.
ISOJ should consist of multipart standards in order to realize ISOJ profiles easily, though the concept of profiling is still possible without multiple standards.
A candidate part structure is the following:
The content of each part is as follows:
Clear and definite ISOJ conformance statements should be declared according to ISOJ profiling scheme.
Two kinds of conformance requirements would be necessary.
Under the assumption of multipart standards, 1) means that a separate conformance requirement should be given in each part.
More detailed conformance related proposal is submitted in another contribution entitled as "Conformance of Java Standards".
SC22 is responsible for the standardization of language and its environment, especially language specification, not for its application. Therefore, category issues may be beyond SC22 matters.
SC22 should concentrate on level issues and the taxonomy of ISOJ profiles, that is, four documents in "3. Multipart Standards for ISO Java". In other words, Reference category and the taxonomy are the main targets of SC22. Some categories but Reference may be targets of SC22 if the works are heavily related to Language issues. Other category related documents should be prepared in other bodies for ISOJ applications. The specification in the documents should be subject to the taxonomy of ISOJ profiles developed in SC22.
The selection of categories which should be developed in SC22 is for further study.