JTC1/SC22
N2843
Date: Tue, 17 Nov 1998 17:35:59 -0500 (EST)
From: "william c. rinehuls" <[email protected]>
To: [email protected]
cc: keld simonsen <[email protected]>
Subject: SC22 N2843 - Minutes and Recommendations from JSG October Meeting
__________________ beginning of title page _____________________________
ISO/IEC JTC 1/SC22
Programming languages, their environments and system software interfaces
Secretariat: U.S.A. (ANSI)
ISO/IEC JTC 1/SC22
N2843
TITLE:
Minutes and Recommendations from the SC22/JSG Meeting on October 26-27,
1998 in Tokyo, Japan
DATE ASSIGNED:
1998-11-17
SOURCE:
Secretariat, ISO/IEC JTC 1/SC22
BACKWARD POINTER:
N/A
DOCUMENT TYPE:
SG Minutes
PROJECT NUMBER:
N/A
STATUS:
N/A
ACTION IDENTIFIER:
FYI
DUE DATE:
N/A
DISTRIBUTION:
text
CROSS REFERENCE:
N/A
DISTRIBUTION FORM:
Open
Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
William C. Rinehuls
8457 Rushing Creek Court
Springfield, VA 22153 USA
Telephone: +1 (703) 912-9680
Fax: +1 (703) 912-2973
email: [email protected]
___________ end of title page; beginning of minutes _________________
Minutes of Java Study Group Meeting, October 26-27, 1998 in Tokyo, Japan
Opening Remarks
Because the meeting was attended by only two national body delegations,
there are only recommendations and no resolutions.
Minutes
1. Conformance of Java standards - such as Multiple levels of conformance
(A. Kido, N3-3 and N3-4)
Discussion: There may be multiple levels of conformance, as proposed in
N3-4.
Question: What happens to applications when the features assumed available
are not available?
Answer: An important question not yet solved.
Comment: In US, NIST real-time group addressed extensions and Sun concluded
that the only possible action, when resources were not available, was to
"exit ungracefully".
2. Subsetting / Profiling
Discussion: Presentation, "ISO Java Standardization Profile" by M.
Uchiyama, and proposal N3-6 for subsets and Java profiles, including JLS
(Java Language Specification), JVM (Java Virtual Machine Specification),
JAPI (Java API Specification).
The basic idea of a proposed profiling scheme is the concept of "level" and
"category". "Level" allows systems without VM and/or some APIs. Level 3
should be equivalent to JDK. "Category" includes correspondents of
specifications such as Personal Java, Embedded Java and Java Card. A matrix
based on level and category gives a taxonomy of profiles, which are
conforming subsets.
Each subset would be a part of ISO Java, e.g., JLS ==> ISO Java, Part 1;
JVM ==> ISO Java, Part 2; JAPI ==> ISO Java, Part 3.
3. Embedded systems / real-time issues
Discussion: Presentation by Tom Plum
http://www.raleigh.ibm.com/maillists/rt-java
http://www.nist.gov/rt-java
To join, send E-mail to [email protected] with message:
subscribe rt-java
Upcoming events:
* Demo at Embedded Systems 98, week of 1998-11-02, Santa Clara, CA, USA
* Requirements Group - "Open" - NIST, next meeting on 1998-12-08 /
1998-12-09 at Chelmsford, MA, US
* "Real-Time Extensions to the Java (tm) Platform" - Sun's "Open Process"
Expert's Group. Sun requires signing a Non-Disclosure Agreement and a
License Agreement to be part of the "Open Process". Generating a
requirements document, not a standard.
4. Overview of JIS/TR (Technical Report) (Y. Komachi)
Discussion: JIS Technical Report types. Similar to JTC1 Technical Report
types.
Issue: How does is the copyright legality compatible with US and European
laws.
Issue: Does Sun have any objection to this?
5. Floating Point Computation (Sun's proposed changes and other work)
(Roger Golliver and others)
Discussion: Report on Sun floating point proposal -- proposal not ready yet
Discussion: Report on a new algorithm to produce "strict" orthogonal IEEE
results on extended IEEE architectures (IA-32). Contact roger for details
or pass on pointer to interested JIT/JVM developers.
Discussion: Java Grande group's efforts to address needs of scientific and
engineering uses of Java. Complex arithmetic, relaxation of evaluation
rules for higher optimization of fp codes, and High-Performance Java (like
HP Fortran).
6. Native Compilation (Salil Pradhan, HP, USA)
Discussion: Presentation from HP on static compilation systems.
Motivation: users want this, works with existing development systems.
Issues: Range checking, it is possible to take advantage of hardware
facilities?
7. Handling of Fully Internationalized Character Code - Support of entire
repertoire of ISO/IEC 10646
Presentation by Akio Kido, IBM Japan, Ltd.
Discussion: Supporting 32-bit characters, as required by ISO-IEC 10646.
Current Java characters are 16-bits. Do not specify encoding scheme and
size of character data type in the Java language standard, make it
processor defined. Mapping between the character datatype in the Java
language and Java ByteCode should be done in a processor defined manner. In
the other words, the implementation which support full repertoire of
ISO/IEC 10646 should have the character data type whose size is more or
equal to 31 bits and handle character data character by character not
16-bit by 16-bit. The operation may be translated into multiple Java
ByteCode statements where the character data is stored as UTF-16 encoding.
Possible change to Java: Amend the current specification of Java 1.1 and
make the size and encoding of character datatype as UCS4 encoding in all
Java standards including Java language, Java ByteCode, and Java API.
Another possible change to Java: Stay the current specification of
character datatype as it is, i.e. UCS2, and:
* allow to store UTF-16 into the string object;
* provide new methods to detect character boundary in the string object;
* provide new character manipulation method that handle character data in
the string object character by character, not by 16bit unit;
* provide new "CHARACTER" datatype and "STRING" class which value space is
entire repertoire of ISO/IEC 10646 and which encoding is UCS4;
* provide set of functions to convert string object which encoding is
UTF-16 to the new "STRING" object that encoding is UCS4, and vise versa.
Discussion: The current Java specification has some problems in non-BMP
plane support. The primitive character data type "char" can't store UCS-4
data directly because its values are 16-bit unsigned integers. Although the
Unicode Standard 2.0 supports surrogate pairs
(UTF-16), there are the following problems in the Java specification.
* Unicode escapes (e.g., \uFFFF) don't support UCS-4 representation.
* Almost all methods in java.lang.Character class don't process surrogate
pairs as one character.
* Because The "CONSTANT_Utf8" format in class files isn't the standard
UTF-8 format, surrogate pairs don't convert correctly.
Recommendation: ISO Java standard should support non-BMP planes in UCS-4.
For
example, additional ideographs will be added to plane 2 in ISO/IEC
10646. Those characters are necessary for reading/writing Japanese
documents.
Discussion: Whereas, one of important application area of Java is World
Wide Web, and in the WWW environment, character encoding of text object in
digital documents should be transparent from end user, since the character
encoding may be converted from one to another during the data transfer from
server to client, or may vary from a Web page to another, and whereas a CC
data element, such as Latin capital character "A" with acute accent may be
represented by a precomposed character in an encoding, but may be
represented by a combining sequence in other encoding, therefore, Java
standard may need to have a set of functionality to access to the CC data
element in a character string.
ISO/IEC 10646 and some other ISO/IEC coded character standards specify
combining characters and composite sequence as well as pre-composed form of
character. For example, a glyph Latin Alphabet Capital Letter A with Acute
may be represented by LATIN CAPITAL LETTER A WITH ACUTE (u00C1) and/or the
sequence of LATIN CAPITAL LETTER A (u0041) followed by COMBINING ACUTE
ACCENT (u0301).
Considering the above duplicate representation of a CC data element, the
World Wide Web Consortium (W3C) is now working to establish "Character
Model in the Web" and has published requirement document as a technical
report:
http://www.w3.org/TR/1998/WD-charreq-19980710
In the document, the W3C mentioned about the requirement on the CC data
element level comparison regardless of the character representation
difference of a CC data element. To achieve the CC data element level
comparison, normalization of ISO/IEC 10646 (Unicode) string may be required
as a pre-handling of the comparison. Also, the Unicode consortium is
working on the normalization technique of Unicode string; see:
http://www.unicode.org/unicode/reports/tr15/
The question is whether such CC data element level access should be done at
application layer by using existing Java API with hardcoding of Unicode
values in the application,
or a set of new Java API which enables the access to the CC data element in
a Java string object should be provided as standard API of the ISO Java
standard. In the latter case, the following two API may be required.
Issues: (1) Convert an un-normalized string object to normalized one. (2)
Detect CC data element boundary in a string object.
8. Encoder converter API - the converter esp. for character code should be
open to users (Y. Mizutani, and M. Suzuki)
Discussion: Missing converters for Java JDK. For example, there are
converters for ASCII, UTF-8, but not DBCS -- and the converters have
inconsistent behavior.
9. JTRON (Java on TRON)
Presentation by Yukikazu Nakamoto of NEC on ITRON Project.
Discussion: Real-time vs. embedded systems.
10. Internationalized documents for Java (T. Kimura)
Discussion: ISO Java standard should specify a mandatory set of
internationalized Java documents and a set of support tools for this
document internationalization. In addition, reference implementations of
the tools may be recommendable.
11. Closer liaison with PAS Submitter (SMI) (A. Kido)
Discussion: Request the convener to request to SC22 to request to JTC1 to
establish a C type liaison between SMI and the Java SG, in order to ensure
tight cooperation between the possible PAS submitter of ISO Java standards
(SMI) and possible responsible standardization body under ISO/IEC JTC1
(Java SG). The cooperation will contribute to establish high quality Java
standards in timely manner.
The establishment of the liaison could be beneficial for both bodies, for
example:
* Java SG can provide support to SMI for preparation of Java standard text
in the ISO/IEC directives part 3 conforming manner.
* In order to maximize approval vote at the PAS ballot, SMI can ask Java SG
to review and comments to a portion of a draft PAS text, in advance.
* Java SG and member bodies of the Java SG can have a chance to express
their opinions. comments, and possible conditions for approval vote to the
PAS text, before the submission of the PAS text.
* In the case if any controversial problems are found through the
pre-review of a draft PAS text, suggested in the second item, Java SG may
be able to discuss the SMI and look for a compromise.
12. Possible changes to the PAS process being discussed by JTC1
Discussion: There is little JSG can to directly affect the PAS process.
13. Relationship to other distributed computing standards -- CORBA, COM,
WWW, etc.
14. Future Meeting Dates: 1999-05-10 / 1999-05-11 in Hawaii, or
alternatively 1999-05-13 / 1999-05-14 in Hawaii
_________________ end of minutes; beginning of recommendations _______
RECOMMENDATIONS FROM THE SC22/JSG MEETING
on October 26-27, 1998 in Tokyo, Japan
Recommendation 1
The Java Study Group requests the convener to ask SC22 to recommend JTC1
establish a category C liaison between expected Java standard PAS submitter
SMI, and the Java Study Group to facilitate closer cooperation between
those groups.
See Java SG N 3-3 http://www.itscj.ipsj.or.jp/eg/documents/jsgn33.txt
Recommendation 2
The Java Study Group requests the convener to ask SC22 to recommend JTC1
requests SMI presents its submission in the form specified by ISO/IEC
Directives, Part 3; in addition, the conformance requirements should be
clearly stated in the text. The Java Study Group is willing to support SMI
in preparation of the standard text.
See Java SG N 3-4 http://www.itscj.ipsj.or.jp/eg/documents/jsgn34.txt
Recommendation 3
Whereas, the Java Study Group recognizes that Java is applied in the areas
of real-time and embedded systems; and
Whereas, these applications require special features or restricted computer
resources;
Therefore, the Java Study Group requests the convener to ask SC22 to
recommend JTC1 requests SMI to allow any Java specifications proposed
through the PAS procedures to have standards profiles.
See Java SG N 3-5 http://www.itscj.ipsj.or.jp/eg/documents/jsgn35.txt and N
3-6 http://www.itscj.ipsj.or.jp/eg/documents/jsgn36.txt
Recommendation 4
Whereas, ISO/IEC JTC1/SC2 is now developing ISO/IEC 10646-2, and defining
characters in planes 1, 2, and 14; and
Whereas, those characters can not be represented by UCS2;
Therefore, the Java Study Group requests the convener to ask SC22 to
recommend JTC1 requests SMI provide a means to support the entire
repertoire of ISO/IEC 10646, including characters outside the BMP.
See Java SG N 3-7 http://www.itscj.ipsj.or.jp/eg/documents/jsgn37.txt and N
3-12 http://www.itscj.ipsj.or.jp/eg/documents/jsgn312.txt
Recommendation 5
Whereas, some current implementations of Java do not implement the entire
set of coded character sets converters included in SMI's JDK package; and
Whereas, this lack of support is an inhibitor to achieve "write once, run
anywhere"; and
Whereas, the Java Study Group recognizes that there is a requirement for
users and IT vendors to add new coded character set converters;
Therefore, the Java Study Group requests the convener to ask SC22 to
recommend JTC1 requests SMI:
1) Specify a mandatory set of coded character set converters;
2) Specify the behavior of the mandatory set of coded character set
converters;
3) Provide a means for users or implementers of Java specifications to add
character set converters;
4) Provide a means for users or implementers of Java specifications to
modify the behavior of existing character set converters;
5) Provide a means to determine the availability of supported code sets.
See Java SG:
N3-9 http://www.itscj.ipsj.or.jp/eg/documents/jsgn309.txt
N3-10 http://www.itscj.ipsj.or.jp/eg/documents/jsgn310.txt
N3-11 http://www.itscj.ipsj.or.jp/eg/documents/jsgn311.txt
N3-14 http://www.itscj.ipsj.or.jp/eg/documents/jsgn314.txt
Recommendation 6
Whereas, the Java Study Group recognizes that issues of Recommendation 5
also exist for internationalization-related resources such as locale;
Therefore, the Java Study Group requests the convener to ask SC22 to
recommend JTC1 requests SMI to specify a mandatory set of
internationalization resources similar to Recommendation 5.
Recommendation 7
The Java Study Group requests the convener to ask SC22 to recommend JTC1
encourages its national bodies to participate in the real-time and floating
point discussions in NIST, http://www.raleigh.ibm.com/maillist/rt-java, and
Java Grande http://www.javagrande.org
Recommendation 8
The Java Study Group requests the convener to schedule the next Java Study
Group meeting on 1999-05-10 / 1999-05-11 in Hawaii, US; or alternately on
1999-05-13 / 1999-05-14 at the same location.
Recommendation thanks
The Java Study Group thanks to ITSCJ for their hosting of the JSG third
meeting.
The Java Study Group thanks the drafting committee: Frank Farance of
Farance Inc., and Masami Suzuki of Microsoft.
The Java Study Group thanks Mariko Takeuchi, Tomomi Haruhana, Junsuke
Miyazaki for secretarial, clerical, and logistics help.
___________________ end of SC22 N2843 ________________________________