From rex@aussie.com Sun Jan 19 14:33:57 1997 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id OAA27157 for ; Sun, 19 Jan 1997 14:33:49 +0100 From: rex@aussie.com Received: from alterdial.UU.NET by relay5.UU.NET with ESMTP (peer crosschecked as: alterdial.UU.NET [192.48.96.22]) id QQbzec00398; Sun, 19 Jan 1997 08:33:47 -0500 (EST) Received: from 205.230.244.18 by alterdial.UU.NET with SMTP (peer crosschecked as: pool018.Max1.FFX1.VA.DYNIP.ALTER.NET [205.230.244.18]) id QQbzec03195; Sun, 19 Jan 1997 08:33:41 -0500 (EST) Date: Sun, 19 Jan 1997 08:33:41 -0500 (EST) Message-Id: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: Cupertino Meeting Minutes To: sc22jsg@dkuug.dk X-Mailer: SPRY Mail Version: 04.00.06.17 Here's my final version of the minutes. My intent was to capture the sentiment rather than to attribute specifics to specific speakers/company affiliations. I know some attendees wrote more notes that I did for their trip reports but in the case of formal ISO meeting minutes, I think less is more. I decided to not include the full contact/affiliation of attendees. Since we are a group of technical experts meeting under ISO's umbrella, I figured names and national affiliations were sufficient. Anyone who cares about affiliations can easily find that out from the reflector/web site. Thanks to the reviewers for their additions/corrections. Rex ------------------------------------------------------------------------ +1 703 860-0091 | Rex Jaeschke | Java, C, C++, FAX +1 703 860-3008 | 2051 Swans Neck Way | Win32 Seminars rex@aussie.com | Reston, Virginia 20191-4023, USA | and Consulting ------------------------------------------------------------------------ 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.