JTC1/SC22
N2406
Date: Wed, 29 Jan 1997 11:51:04 -0500 (EST)
From: "william c. rinehuls" <rinehuls@access.digex.net>
To: sc22docs@dkuug.dk
Subject: SC22 N2406 - Minutes of SC22/Java Study Group 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
N2406
February 1997
TITLE: Minutes of SC22/JSG (Java* Study Group) Meeting
on January 7-8, 1997 in Cupertino, California, USA
SOURCE: Secretariat, ISO/IEC JTC 1/SC22
WORK ITEM: N/A
STATUS: N/A
CROSS REFERENCE: N/A
DOCUMENT TYPE: SC22/JSG Meeting Minutes
ACTION: To SC22 Member Bodies for information.
* Java is a trademark of Sun Microsystems
Address reply to:
ISO/IEC JTC 1/SC22 Secretariat
William C. Rinehuls
8457 Rushing Creek Court
Springfield, VA 22153 USA
Tel: +1 (703) 912-9680
Fax: +1 (703) 912-2973
email: rinehuls@access.digex.net
_________________ end of title page; beginning of text ___________________
SC22 Java(TM) Study Group (JSG) Meeting Minutes
JavaSoft/Apple, Cupertino, California
January 7-8, 1997
Java is a trademark of Sun Microsystems
Tuesday January 7
1. 09:00-11:00 JSG participants met jointly with SC29/WG12 (MHEG) and
heard presentations on MHEG5 and MHEG6.
The MHEG6 standard likely will include the text descriptions of the JVM
and the packages java.lang and java.util, since these do not currently
exist as standards and so cannot be referenced in an ISO standard. Their
draft is based on the V1.0 specs as published in the Sun/Addison-Wesley
books. They likely would consider updating to V1.1 when it becomes
available. Apparently, V1.1's java.lang somehow involves java.io, so they
might eventually include the java.io package in their spec as well.
The question was raised about how they would handle Defect Reports for the
material they intend to include. MHEG6 hasn't thought through yet how
maintenance will/might work. It seems that they would rather reference
existing standards for JVM and core classes if/once they exist. Afterall,
they are a user of the JVM/core class facilities, not a producer. However,
they plan to move to an IS by the end of 1997.
2. The JSG meeting proper commenced at 13:00 with Bob Mathis as chair.
Rex Jaeschke acted as secretary.
The following people were in attendance:
Magnus Alvestad (Norway)
John Benito (USA)
Dan Bornstein (USA)
Steve Carson (SC24 liaison)
Joseph Coha (USA)
Sean Corfield (UK)
Harley Davis (France)
Frank Farance (USA)
Charles Fitzgerald (USA)
Rex Jaeschke (USA)
Scott Jameson (USA)
Bob Jervis (USA)
E. Andrew Johnson (USA)
Derek Jones (UK)
Toshiaki Kurokawa (Japan)
Dmitry Lenkov (USA)
Brian Marks (UK)
Bob Mathis (Convener)
Karl Matzke (USA)
Brad Merrill (USA)
Randy Meyers (USA)
Kevin Miller (USA)
Janice Shepherd (USA)
Peter Smith (USA)
Valerie Taylor (USA)
Simon Tooke (Canada)
Ken Urquhart (USA)
Wayne Winder (USA)
Neil Martin (from the UK delegation) sent a formal note saying he was
unable to attend.
6 countries were represented: Canada, France, Japan, Norway, UK, and USA.
Everyone introduced themselves. A broad cross-section of interests were
represented with participants having a wide range of experience working in
various national and international standards groups. SC24 (graphics) was
represented; this group is interested in JVM and libraries. SC29 was also
represented.
3. James Mitchell, Chief Scientist, JavaSoft, addressed the group. Here
are the main points he made directly or in response to questions from the
floor:
* Sun's approach to Java is to make it open.
* Sun wants there to be no subsetting.
* Sun has a need to protect their investment (the Java brand is a big
asset) and this conflicts somewhat with the idea of complete openness.
* It's a bad idea to standardize things before they are well cooked.
* Sun has had dialog with various standards groups including ECMA, ISO,
IEEE, OpenGroup, and others regarding Java standardization. Sun prefers a
clean/fast method. Made it quite clear they don't want it to get hung up
in a large committee intent on design. (He cited the C++ standardization
effort as a very bad example of this.)
* Discussed the strong need to validate/verify implementations.
* Discussed branding issues with respect to the OpenGroup.
* In response to a question about ``how will Sun know when it's cooked'',
there was a discussion about getting started down the standard's path
before Sun's thinking it's cooked enough. A lot can be done without
having all components 100% cooked.
4. 14:20 JSG reconvened with SC29, with more questions being addressed by
the MHEG6 presenter, Dr. Xavier Marie.
We revisited the issue of interpretation of the JVM/class part of MHEG6.
We were informed that ISO and JTC1 can make normative references to
non-ISO documents such as books. In fact, SC24 has made references to one
or more of the Java specification books. However, this leads to the issue
of how to resolve interpretations of material from those sources.
Why can't JSG simply wrap a cover page and some interpretation process
material around the existing Java spec(s) and call that the new standard?
Apparently, the JTC1 rules do not allow a standard to be
substantially/completely a reference to an external source.
MHEG plans to resolve comments on its CD ballot at this week's meeting. At
its July meeting it will deal with any IS ballot results. Then it expects
to have the IS adopted in November, 1997.
Then followed a discussion of how the MHEG might work together with the
JSG to make something happen. MHEG has 15-30 people at meetings
representing up to 10 national bodies, meeting three times per year plus
one or more ad-hoc sessions. Since JSG has not yet discussed its own
agenda much, it was agreed that Bob Mathis would report back to MHEG
tomorrow afternoon once JSG had formed an opinion. Mathis thought that JSG
could react very quickly once Sun authorized the use of the appropriate
material for base documents. The important issue regarding timing is that
JSG need not wait until the SC22 Plenary in August to get started on some
sort of standardization effort.
5. ECMA TC39 JavaScript/ECMA Script
What is our position, if any, on this effort?
Afnor (the French National Body) is of the opinion that JSG should be
involved in the production of this standard.
There were concerns about the suitability of the JavaScript specification
as a base document. Also, perhaps this work should be done within SC22.
A majority thought that ECMA Script is an important technology. (It was
claimed that JavaScript currently has an order of two more users than
Java.)
It was suggested that an ISO standard is inappropriate for a language
whose life is short. Just what is the life-span of these scripting
languages?
Is there any point in pursuing an ISO standard on top of an ECMA standard?
Won't ECMA's members be going off to implement what they approve regardless
of what ISO might come up with later?
straw votes:
9/7/4 in favor of reviewing ECMA documents in some sort of liaison role
14/1/4 in favor of ECMA producing and keeping the standard
0/lots in favor of SC22 producing a standard
6. ActiveX presentation by Charles Fitzgerald, Microsoft.
ActiveX is a language-, application-, platform-, and O/S-neutral component
architecture (whereas JavaBeans is Java-specific).
Microsoft's JVM has been extended to integrate Java with other code and the
rest of the computing environment.
Gave a status report on the hand-over of related documents to the
OpenGroup.
Microsoft sees the need for a lot more maturity (performance, robustness
and functionality) before Java really is useable for heavy-duty
applications.
Microsoft thinks that the next year is critical for Java. Would like to see
a conformance test suite come out from a neutral body.
There seems to be two ways to go: either produce an ISO standard or fight
it out in the commercial marketplace. Microsoft is prepared to go either
way.
There was a discussion regarding whether or not JSG should be involved in
ActiveX. Apparently, this is premature since the OpenGroup hasn't really
gotten things going yet.
For more information about the OpenGroup/ActiveX project, refer to
www.xopen.org, in general, and www.xopen.org/press/18dec96.htm
specifically.
7. ANDF presentation by Andy Johnson, OSF.
ANDF stands for Architecture-Neutral Distribution Format (the original RFP
was issued by OSF). It is a tree-structured intermediate representation of
a program. OSF produced a validation suite.
ANDF is an X/Open specification (the current level is revision 4).
It's important that some of the experiences learned with the ANDF project
be passed on to those working on a JVM standard.
What is the interest level of this group in continued discussion on ANDF,
now or in the future? No interest.
8. Other Technologies
Lucent Technologies' Inferno, Gazelle/Juice, ScriptEase (Cmm) from Nombas:
These topics had been mentioned in passing over the reflector but there
seems to not be any interest in pursuing them further.
Wednesday January 8
9. Java-Specific issues
It was suggested that we should separate the language/core classes from
the JVM. There are two distinct audiences: end user and back-end. MHEG has
no interest in the language; their primary interest is in the JVM.
However, there is such a strong connection between the two parts that they
shouldn't be too separate.
Several people want to be able to have languages other than Java target
the JVM.
We discussed possible ways of breaking up the parts. Just what does the
term Java imply? All of the Language, libraries, and JVM? Some people
thought that the language need not be present before a product can be
labelled Java.
In reality, we'll probably need a subset version for the purposes of
embedded systems. (The ISO C standard's hosted vs. freestanding library
was cited as an example of providing this option.)
What are the possible scenarios regarding how Sun might proceed:
* Get active in the standard's process
* Adopt a neutral attitude
* Maintain it themselves
Possible component breakdown:
* Language
* Core classes
* JVM
* Other APIs (done by a Java group or by other WGs)
Since Sun has been speaking with various standards group, perhaps we
should demonstrate to them the kinds of things we can do and how we can
help them improve the quality of their current specifications. We might
also agree to not make changes in the first round but rather, just add
clarifications.
We were reminded that Sun appears to be interested in some sort of ``fast
track'' process with minimal change. Maybe they could get ECMA to produce
a standard ``as is'' then have ISO/SC22 adopt that and take it on for
further development.
10. NetRexx, Brian Marks, IBM.
A 1-page handout was provided re IBM's NetRexx product. This product
allows programs and applets to be created for the Java environment.
Brian asked if the group would include the writing up of a new work
project for NetRexx as part of its tasks; the group declined.
11. What to do with Java
There was a discussion to help a drafting committee write a resolution.
There was considerable agreement on our inviting Sun to work with us in a
cooperative relationship.
12. Resolutions:
R-1: ECMA Script:
p1. JSG acknowledges the need to standardize ECMA Script and is encouraged
that ECMA TC39 is actively working towards this goal.
p2. JSG feels that no additional standards activity on ECMA Script should
be undertaken by ISO at this time.
p3. JSG invites ECMA TC39 to make drafts of the ECMA Script standard
available to JSG via its convener, so that individual members can
contribute comments during the review process.
R-2: MHEG
p1. SC22/JSG is interested in standardizing the JVM as quickly as possible
in conjunction with Sun.
p2. SC22/JSG wants to work with the language and application committees
that are interested in the JVM.
p3. Until an ISO standard exists for the JVM, SC22/JSG suggests MHEG6
reference the Addison-Wesley books.
R-3: Formal Submission to Sun Microsystems
p1. The ISO/IEC JTC1/SC22 JSG invites Sun Microsystems to submit the Java
Core Technology for processing as an ISO standard or standards. To
encourage Sun Microsystems to adopt this approach rather than other routes
to standardization, we note that:
* ISO has the widest world recognition and ISO standards meet many
regulatory requirements.
* The scope of an SC22 project can be narrowly defined; for example, a
project can be limited to producing clarifications only, from a
designated base document.
* A tightly controlled scope can be used to expedite project deliverables.
* The development of standards can be timed to match the maturity of
different components of the technology.
* We believe that ISO policies would allow a cooperative agreement that
would satisfy Sun Microsystems, for example on:
Intellectual property rights
Brand naming
p2. If it occurs that the initial standards are developed outside of ISO
auspices, the Java Study Group suggests that subsequent development should
occur in ISO/IEC JTC1/SC22.
R-4: Java Technical Issues List
p1. JSG plans to form a Java Technical Issues List, the primary purpose of
which is to add clarification, especially with respect to unspecified
behavior. This activity is not intended to amend/change/rewrite the
existing text and we are not interested in editorial comments. The base
documents for which input would be solicited are:
* ``The Java Language Specification'' by James Gosling, Bill Joy, and Guy
Steele, ISBN 0-201-63451-1, Addison-Wesley, 1996.
* ``The Java Class Libraries: An Annotated Reference'' by Patrick Chan and
Rosanna Lee, ISBN 0-201-63458-9, Addison-Wesley, 1996.
* ``The Java Virtual Machine Specification'' by Tim Lindholm and Frank
Yellin, ISBN 0-201-63452-X, Addison-Wesley, 1996.
p2. There would be a read-only public repository of information which would
be maintained by a list master. Submissions and updates to existing
submissions would be made to the list master who would periodically post
them to the public repository as well as to the e-mail reflector.
p3. Details of submission formats and procedures have yet to be resolved.
The authors of these books will be contacted beforehand, however, to
discuss how we might best work together on this project.
13. Future meetings:
* June 30-July 1, London, UK, hosted by BSI.
14. Action items:
Rex Jaeschke
* Distribute the meeting minutes
* Refine the technical issues list procedures
Bob Mathis
* Forward our statement to JavaSoft
* Establish a date and host for an April meeting
* Respond to MHEG
* Respond to ECMA TC39
* Write a short summary of the meeting for general release
Derek Jones IST5-53, UK Java Panel
* Investigate BSI's hosting of a June meeting in the UK
15. Miscellaneous Items
Thanks to our meeting hosts JavaSoft and Apple.
Derek Jones (derek@knosof.co.uk) invited interested parties to attend the
UK Java Panel meeting on February 7 at 14:00 at BSI.
16. The meeting adjourned at approximately 15:10.
_______________________end of SC22 N2406 _________________________________