|
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
|
JCP Procedures
JCP 2.0: Process Document
JCP 2.11 |
JCP 2.10 |
JCP 2.9 |
JCP 2.8 |
JCP 2.7 |
JCP 2.6 |
JCP 2.5 |
JCP 2.1 |
JCP 2.0 |
JCP 1.0
The 2.0 revision of the formal procedures for using the Java Specification development process. Please see JCP 2: Process Document for the current version.
Version 2.0 (June 2, 2000)
CONTENTS
EXECUTIVE SUMMARY
The international Java community develops and evolves Java™ technology specifications using the Java Community Process (JCP). The JCP produces high-quality specifications in "Internet time" using an inclusive, consensus building approach that produces a specification, a reference implementation (to prove the specification can be implemented), and a technology compatibility kit (a suite of tests, tools, and documentation that is used to test implementations for compliance with the specification). Experience has shown that the best way to produce a technology specification is to gather a group of industry experts who have a deep understanding of the technology in question and then have a strong technical lead work with that group to create a first draft. Consensus around the form and content of the draft is then built using an iterative review process that allows an ever-widening audience to review and comment on the document. This version of the JCP was developed by Sun based on input from leading Java partners. In this version, an Executive Committee (EC) representing a cross-section of both major stakeholders and other members of the Java community is responsible for approving the passage of specifications through key points of the JCP and for reconciling discrepancies between specifications and their associated test suites. There are two ECs: one to oversee the Java technologies for the desktop/server space (with responsibility for the J2SE™ and J2EE™ specifications) and the other to oversee the Java technologies for the consumer/embedded space (with responsibility for the J2ME™ specification). There are four major steps in this version of the JCP:
Java Community Process (JCP): The formal process described in this document for developing or revising Java technology specifications. Java Community Process Member (Member): A company, organization, or individual that has signed the JSPA and is abiding by its terms. Java Specification Participation Agreement (JSPA): A one-year renewable agreement between Sun Microsystems and a company, organization or individual that allows the latter entities to participate in the Java Community Process. Individual Expert Participation Agreement (IEPA): An agreement between Sun Microsystems and an individual that allows that individual to serve on an Expert Group at the invitation of the Specification Lead. There is no fee associated with the IEPA and it is valid until the Expert Group disbands. The IEPA allows individual technical experts who do not represent companies or organizations to participate on Expert Groups. Executive Committee (EC): The Members who guide the evolution of the Java technologies. The EC represents a cross-section of both major stakeholders and other Members of the Java Community. Members must have signed the EC acceptance letter in order to serve on the EC. The EC Policies and Procedures are in Appendix A. Program Management Office (PMO): The group within Sun Microsystems that is responsible for administering the JCP and chairing the EC. Java Specification (Specification): A written specification for some aspect of the Java technology. This includes the language, virtual machine, Platform Editions, Profiles, and application programming interfaces. Platform Edition Specification (Platform Edition): A Specification that defines a baseline API set that provides a foundation upon which applications, other APIs, and Profiles can be built. There are currently three Platform Edition Specifications: J2SE, J2EE, and J2ME. Profile Specification (Profile): A Specification that references one of the Platform Edition Specifications and zero or more other JCP Specifications (that are not already a part of a Platform Edition Specification). APIs from the referenced Platform Edition must be included according to the referencing rules set out in that Platform Edition Specification. Other referenced specifications must be referenced in their entirety. Reference Implementation (RI): The prototype or "proof of concept" implementation of a Specification. Technology Compatibility Kit (TCK): The suite of tests, tools, and documentation that allows an implementor of a Specification to determine if their implementation is compliant with that Specification. JCP Web Site: The web site where anyone with an Internet connection can stay informed about JCP activities, download draft and final Specifications, and follow the progress of Specifications through the JCP. JCP Specification Page (Spec Page): Each Specification approved for development or revision will have a dedicated public web page established on the JCP Web Site to contain a history of the passage of the Specification through the JCP, including a record of the decisions, actions, and votes taken by the EC with respect to the draft Specification. THE JAVA COMMUNITY PROCESSSM PROGRAM
1. INITIATE A NEW OR REVISED SPECIFICATION
1.1 INITIATE A JAVA SPECIFICATION REQUEST
One or more Members can initiate a request to develop a new Specification, or carry out a significant revision to an existing one, by sending a JSR to the PMO. The JSR should follow the template available at the JCP Web Site. The JSR serves to identify the Members making the request (the sponsors), a Specification Lead, and the initial members of the Expert Group. It will also describe the proposed Specification, the reason(s) for developing or revising it, the primary target Java Platform Edition, an estimated development schedule, and any preexisting documents, technology descriptions, or implementations that might be used as a starting point. Any JSR under consideration can be withdrawn by its sponsors without explanation at any time prior to the completion of the JSR approval vote (see section 1.3) upon request by the initiator(s) to the PMO. 1.1.1 REVISE EXISTING SPECIFICATIONSExisting Specifications, along with their associated RIs and TCKs, are maintained by a designated Maintenance Lead using the processes described in section 4 of this document. Maintenance Leads (and their host company or organization) are expected to assume long term ownership of their Specification, RI, and TCK with due respect of the will of the Java Community Members with regard to evolution. This means that a Maintenance Lead will automatically be the Spec Lead for all significant revisions to their Specification going forward but he or she will not have the exclusive right to decide when a significant revision will take place. That will be decided by the EC in response to a revision JSR that can be initiated by any Java Community Member (or Members). The only provision is that the initiator(s) should make a reasonable effort to get some of the members of the previous Expert Group to join the revision effort. 1.1.2 PROTECT THE INSTALLED BASE AND GUARD AGAINST FRAGMENTATIONChanges to the Java programming language, the Java virtual machine (JVM), the Java Native Interface (JNI), packages in the "java.*" space, or other packages delivered as part of J2SE, have the potential to seriously disrupt the installed base if carried out inconsistently across the Platform Editions. In order to protect the installed base, any such changes can only be accepted and carried out within a UJSR for J2SE. In order to guard against fragmentation, new Platform Edition Specifications will not substantially duplicate existing Platform Editions or Profiles. 1.1.3 PROFILES AND API SPECIFICATIONS TARGET CURRENT PLATFORM EDITIONSAll new or revised Specifications must be compatible with the most recent versions of the targeted Platform Edition Specifications. In order to achieve this, all UJSRs to define new Profile Specifications, or revise existing Profile Specifications, must reference the latest version of the Platform Edition Specification they are based upon. 1.1.4 J2ME PROFILES AND J2ME BUILDING BLOCKSdefinition - J2ME Building Block (Building Block): A subset of one or more APIs defined in the J2SE or J2EE Platform Edition Specifications. The J2ME Platform Edition Specification is a collection of Building Blocks. J2ME Profile Specifications can build up desired functionality by combining new API sets with existing Building Blocks. J2ME Profiles will normally be based upon the existing Java virtual machine and language Specifications. When such profiles also need to include subsets of J2SE and/or J2EE functionality, they will reference J2ME Building Blocks. Building Blocks are created and revised within the UJSR for the J2ME Platform Specification. It is likely that different J2ME Profiles will require different J2SE/J2EE subsets. For example, different categories of devices may need different subsets of the "java.net" package. In order to accommodate this, no fundamental restrictions are placed upon the number of times or ways in which J2SE/J2EE functionality can be packaged into J2ME Building Blocks. Building Blocks can be proposed in a UJSR for the J2ME Specification. However, it is recognized that the consumer and device marketplaces can change very rapidly in comparison to the desktop and server marketplaces. The definition of new Building Blocks (as well as the revision of existing blocks) may need to be carried out very quickly in order for some J2ME Profiles to keep up with changing market needs. In the interest of speed, J2ME Building Blocks may also be defined and revised within the JCP Maintenance Cycle (see section 4.2) for the J2ME Specification. Expert Groups that need to quickly create or update a J2ME Building Block should approach the Maintenance Lead for the J2ME Platform Edition Specification with their requests. The J2ME Maintenance Lead, after consultation with both the J2ME Expert Group and the Maintenance Lead(s) of the Platform Edition(s) the block is to be derived from, may propose the new Building Block as part of a maintenance update to the J2ME specification. Note that the EC can require any Building Block proposed as part of the Maintenance Cycle to be defined in a major revision to the J2ME Specification (see section 4.2.2). If the Maintenance Lead declines a Building Block request, the requesting Expert Group has the options of initiating a UJSR for J2ME (which may be time consuming) or creating the needed APIs in any namespace not reserved for use by existing Platform Edition Specifications. In exceptional circumstances, the J2ME Specification may define J2ME Building Blocks for use with special classes of devices that can only implement subsets of the Java virtual machine or language Specifications. Such Building Blocks can be defined and approved only within a UJSR for J2ME. They cannot be defined using the Maintenance Cycle because proposals for Building Blocks for these special classes of devices must be subject to the widest possible review. 1.2 JSR REVIEW
When a JSR is received, the PMO will give it a tracking number, assign the JSR to the appropriate EC, create its JSR Page, announce the proposed JSR to the public, and begin JSR Review. Comments on the JSR should be sent to the e-mail address listed on the JSR Page. All comments received will be made available from the JSR Page and forwarded to the EC for their consideration. Members who are interested in joining the Expert Group (should the JSR be approved) should identify themselves by submitting a nomination form to the PMO. 1.3 JSR APPROVAL BALLOT
During JSR Review, EC members should review the JSR (with its proposed Spec Lead and initial Expert Group), any comments and nominations received, and cast their ballot to decide if the JSR should be approved.
If the JSR Approval Ballot fails, the PMO will send all EC comments to the JSR initiators who will have the option of revising the JSR and resubmitting it to the PMO within 14 days. If a revised JSR is not received in that time, the original EC decision will stand and the JSR will be closed. If a revised JSR is received, the PMO will post it to the JSR Page, announce the revised JSR to the public, and send it to all EC members for a JSR Reconsideration Ballot. If that ballot fails, the JSR will be closed.
2.1 FORM THE EXPERT GROUPWhen a JSR is approved, the PMO will notify the identified Spec Lead to form the Expert Group. If the Member contributing the Spec Lead withdraws from the Community before the JSR is approved, the PMO will request the initial Expert Group to choose a replacement from among themselves who is willing to take on the duties defined in this document (including taking responsibility for the RI and TCK, working towards the estimated schedule given in the JSR, and assuming the position of Maintenance Lead as described in section 4). There is no size limit on the Expert Group. The Spec Lead may add additional Experts at any time provided the existing Expert Group is consulted first. New members may be added, for example, to increase diversity of opinion. A Spec Lead recruits new Experts by approaching other Members directly and working with them to identify an expert and bring him or her into the Expert Group. Individual experts can be brought into the Expert Group if they sign an IEPA. 2.1.1 FREEDOM OF WORKING STYLEEach Expert Group is free to define and follow whatever working style it finds most productive and appropriate as long as it is compatible with the JCP. Use of the Internet is encouraged. E-mail exchanges on mailing lists established for the use by the Expert Group, along with conference calls and group meetings, have been used by past Expert Groups to discuss and resolve issues raised as the draft evolves. In-person group meetings are useful but they tend to slow down work considerably due to the need to coordinate schedules. 2.1.2 WITHDRAWAL OF AN EXPERT FROM THE EXPERT GROUPAn Expert may withdraw from the Expert Group at any time. When this happens, the Spec Lead may approach the Member who originally contributed the Expert and work with them to find a replacement. If no replacement is offered, the Spec Lead may recruit a replacement from another Member if desired. If the departing Expert is the Spec Lead, the Expert Group should choose one of their members as the new Spec Lead provided he or she is willing to take on all of the responsibilities defined in this document. 2.1.3 UNCOOPERATIVE OR UNRESPONSIVE EXPERT GROUP MEMBERSThere may be rare instances when members of the Expert Group feel that one of their fellow Experts is not acting in ways that advance the work of the Expert Group. These concerns should be brought to the attention of the Spec Lead and/or the EC as quickly as possible so they may be proactively addressed and resolved. The Expert Group is expected to make a reasonable effort to resolve any such issues among themselves. If a 2/3 majority of the members of the Expert Group find that a Spec Lead is being unresponsive, and the Spec Lead does not work to resolve the situation in a timely manner, the EC may direct the PMO to ask the Member who provided the Spec Lead to provide a replacement. 2.2 WRITE THE FIRST DRAFT OF THE SPECIFICATIONThe Expert Group should begin work by considering the requirements set forth in the JSR, any contributed documents or technology descriptions, comments received during JSR Review and, if this is a revision of an existing Specification, the Change Log kept by the Maintenance Lead (see section 4). Additional input can be obtained from discussions with other Members, industry groups, software developers, end-users, and academics. The goal is to define requirements and then write a draft suitable for review by the Community. When the Expert Group decides that the first draft is ready for review, the Specification Lead will send the draft, along with any additional files required for review, to the PMO. The Specification Lead should also suggest the length of the Community Review period if the Expert Group feels it should go beyond the minimum 30 days. 2.2.1 EARLY WARNING AND FEEDBACK ON LICENSING TERMS FOR THE RI AND TCKThe Spec Lead's company or organization is responsible for the Reference Implementation (RI) and Technology Compatibility Kit (TCK) and its licensing under terms compatible with the licensing guidelines established for use within the JCP. The Spec Lead will provide the EC with the terms under which the RI and TCK will be licensed no later than the start of Community Review. EC members will provide feedback on the terms as an indication of how the Community might react as a whole to the terms. 2.3 COMMUNITY REVIEW
Refinement of the draft Specification begins when the PMO posts it to JCP Web Site and announces the start of Community Review to all of the Members. The goal of Community Review is to get the draft Specification into a form suitable for Public Review as quickly as possible by uncovering and correcting major problems with the draft. All comments from Members should be sent to the e-mail feedback address listed in the draft. The Spec Lead is responsible for ensuring that all Member comments are considered and responded to. For simplicity, similar comments may be combined and responded to as one. 2.3.1 UPDATING THE DRAFT DURING COMMUNITY REVIEWIf the Expert Group makes major revisions to the draft during Community Review, the Spec Lead should send the revised draft, along with a synopsis of the changes, to the PMO at any time up until the last 7 days of the review period (the draft is frozen during the last 7 days of Community Review in order for the EC to complete their Draft Specification Approval Ballot). The PMO will notify Members of any updated drafts and change synopses received and make them available to them for download. During Community Review, EC members are strongly encouraged to have one or more technical members of their organization carry out a review of the draft in order to uncover possible overlap between the draft and other Specification(s) or duplication of features or services already provided by other Specifications. EC members should inform the Expert Group of any such discoveries using the Member e-mail feedback address listed in the draft so they can be considered and responded to like all Member comments. 2.4 DRAFT SPECIFICATION APPROVAL BALLOT
The Draft Specification Approval Ballot is carried out during the last 7 days of Community Review. At the close of balloting, all comments submitted by EC members with their ballots will be circulated to the Expert Group by the PMO.
If the Draft Specification Ballot fails, the Expert Group will have 30 days to update the draft in response to the concerns raised by the EC and submit a revised version to the PMO. If a revised draft is not received by the end of the 30 days, the original decision by the EC will stand and the JSR will be closed. If a revision is received, the PMO will forward it to the EC and initiate a Draft Specification Reconsideration Ballot. At the close of balloting, all comments submitted by EC members with their ballots will be circulated to the Expert Group by the PMO. If this ballot fails, the JSR will be closed and the Expert Group will disband. If the JSR was a revision to an existing Specification, the Spec Lead will resume the role of Maintenance Lead of the current Specification (see section 4). If the Draft Specification Approval Ballot (or reconsideration ballot) is successful, the Expert Group can make any additional changes to the draft they deem necessary in response to EC ballot comments before submitting the draft to the PMO for Public Review. 3. COMPLETE THE SPECIFICATION
3.1 PUBLIC REVIEW
Public Review begins when the PMO posts the draft Specification that was approved by the EC during Community Review on the JCP Web Site and announces it to both Members and the public. Anyone with access to the Internet can download and comment on the draft. Public Review is an important part of the JCP. In the past, comments from the public have raised fundamental architectural and technological issues that have considerably improved some Specifications. The Spec Lead is responsible for ensuring that all public comments are read and considered. If those comments result in revisions to the draft, and those revisions result in major changes (in the opinion of the Expert Group), then the Specification Lead will send an updated draft (with synopsis of the changes) to the PMO who will post both items to the JCP Web Site and notify both Members and the public. 3.2 PROPOSED FINAL DRAFT
After the close of Public Review, the Expert Group will prepare the Proposed Final Draft of the Specification by completing any revisions they deem necessary in response to comments received. The Spec Lead will then send the Proposed Final Draft to the PMO who will announce it to both Members and the public and post it on the JCP Web Site for public download. 3.2.1 COMPLETE THE RI AND TCKThe Spec Lead is responsible for the completion of both the Reference Implementation (RI) and Technology Compatibility Kit (TCK). If the RI and TCK uncover areas of the Specification that were under-defined, incomplete, or ambiguous, the Spec Lead will work with the Expert Group to correct those deficiencies and then send a revised Specification (with synopsis of the changes) to the PMO. All such revisions and change synopses received will be posted to the JCP Web Site and announced to both Members and the public. The Expert Group will continue to consider any further comments received during this time. 3.2.2 ESTABLISH A FIRST-LEVEL TCK APPEALS PROCESS
The Spec Lead is also responsible for establishing a clearly defined First Level TCK Appeals Process to address challenges to the tests contained in the TCK. This process must be described in the documentation included in the TCK (see Section 4.3 for information on the full TCK Appeals Process). Examples of First Level TCK Appeals Process applicable to situations ranging from simple API Specifications all the way up to Platform Edition Specifications can be found in the TCK section of the JCP Web Site. 3.3 FINAL APPROVAL BALLOT
When the Expert Group is satisfied that the TCK provides adequate test coverage, the RI adequately implements the Specification, and the RI passes the TCK, the Spec Lead will send the Final Draft of the Specification to the PMO along with instructions on how EC members can obtain the RI and TCK for evaluation. The PMO will circulate the materials to the EC and initiate the Final Approval Ballot. At the close of balloting, all EC comments will be sent to the Expert Group by the PMO.
If the Final Approval Ballot fails, the Spec Lead will have 30 days to revise the RI and/or TCK in response to any EC concerns. At the same time, the Expert Group will have 30 days to revise the Final Draft in response to any EC concerns and send it to the PMO. If no responses are received by the end of the 30 days, the original decision of the EC will stand, the PMO will close the JSR, and the Expert Group will disband. If the JSR was a revision to an existing Specification, the Spec Lead will resume the role of Maintenance Lead of the current Specification (see section 4). If a response is received, the PMO will circulate it to all EC members for a Final Approval Reconsideration Ballot. At the close of balloting, all ballot comments submitted by EC members will be circulated to the Expert Group by the PMO. If the reconsideration ballot fails, the JSR will be closed and the Expert Group will disband. If the JSR was a revision to an existing Specification, the Spec Lead will resume the role of Maintenance Lead of the current Specification. 3.4 FINAL RELEASESpecifications that are approved by the EC during the Final Approval Ballot (or the reconsideration ballot) will be posted by the PMO on the JCP Web Site and an announcement made to both Members and the public. Upon Final Release, the Expert Group will have completed its work and disbands. 4. MAINTENANCE
4.1 KEEP THE SPECIFICATION UP TO DATE
The Maintenance Lead is responsible for carrying out maintenance on the Specification and dealing with errata by fielding requests for clarification, interpretation, and enhancements to the Specification from both Members and the public via an e-mail address listed in the Specification. The ML will consider all requests and will decide how and if the Specification should be updated in response. The ML will typically be the Spec Lead from the Expert Group that developed the Specification. The ML is not required to do all these tasks by himself or herself. The ML may find it very helpful to recruit members of the Expert Group that helped to develop the Specification to assist with the Maintenance duties. 4.1.1 THE MAINTENANCE LEAD MAKES A LONG TERM COMMITMENTThe Maintenance Lead (and his or her host company or organization) is expected to assume long term ownership of the Specification, RI, and TCK with due respect of the will of the Java Community Members with regard to evolution. This means that a Maintenance Lead will automatically be the Spec Lead for all significant revisions to their Specification going forward but he or she will not have the exclusive right to decide when a significant revision will take place (see section 1.1.1). 4.1.2 RELINQUISHING OWNERSHIP
If the ML decides to discontinue his or her work for whatever reason (including discontinuing maintenance activities or declining to take on the role of Spec Lead during a significant revision initiated by a JSR) the ML should make a reasonable effort to locate another Member who is willing to take on the task. If the ML fails to find a replacement, the PMO will declare the Specification to be Dormant. No further maintenance will be carried out on it until a new ML is identified and ownership of the Specification, RI, and TCK is transferred to the new ML's organization (subject to a successful Transfer ballot by the EC). 4.2 THE MAINTENANCE CYCLEThe ML will review all comments, identify common themes, and arrange with the PMO to make a list of frequently raised issues available from the document's Spec Page. The ML is free to consult with the former members of the Expert Group, or any other sources, for advice on how to revise the Specification. All change items proposed by the ML will make their way into the Specification by either the Minor Revision process (described in section 4.2.1) or by a JSR. 4.2.1 MINOR REVISION PROCESS
The ML will arrange to have all change items placed into the PROPOSED section of the Change Log and then send a request to the PMO to initiate a Maintenance Review. The PMO will make a public announcement and begin the review. The ML may choose to modify one or more of the proposed changes based on comments received during review. All comments will be available from the Spec Page. At the end of Maintenance Review, the ML will update the Specification, document all revisions in the ACCEPTED section of the Change Log, and delete the corresponding entries in the PROPOSED section. All changes not incorporated into the Specification may be either left in the PROPOSED section or moved to the DEFERRED section. 4.2.2 THE EC MAY DEFER MINOR REVISION ITEMS
During Maintenance Review an EC member may request that specific proposed change items be deferred to the next JSR. Any such request must be made to the PMO no later than 7 days before the close of Maintenance Review. If requests are received, the PMO will circulate the requests to all EC members and initiate an Item Exception Ballot during the last 7 days of the review. At the close of Maintenance Review, the PMO will post the ballot results to the Change Log. The ML will place all proposed changes that were disapproved into the DEFERRED section. The ML will need to initiate a JSR to carry out any of those changes. 4.2.3 KEEPING THE RI AND TCK SYNCHRONIZED WITH THE SPECIFICATIONWhenever the Specification is updated, the ML is responsible for reviewing the current RI and TCK to determine what revisions (if any) are needed to keep the RI and TCK synchronized with the Specification. The maintenance changes will be considered final when the RI and TCK are synchronized with the Specification. 4.3 THE TCK APPEALS PROCESSAs noted in section 3.2.2, the TCK documentation must identify and specify a First-Level TCK Appeals Process by which challenges to the TCK will be addressed. An implementor of a Specification can challenge a TCK test using the First-Level TCK Appeals Process. Implementors who are not satisfied with a first level decision can appeal it to the EC. 4.3.1 APPEALING A FIRST-LEVEL DECISION TO THE EC
Implementors appeal a first-level decision to the EC by filing a written request with the PMO using the online form available at the TCK section of the JCP Web Site. The PMO will circulate the request to the EC, along with any information received from the ML concerning the rationale for the first-level decision, and initiate an Appeal Ballot. 4.3.2 UPDATE THE RI TO MATCH THE TCK AND THE SPECIFICATIONIf the Appeal Ballot is successful, the ML will update the TCK and/or the Specification in accordance with the EC decision and update the RI if necessary. APPENDIX A: EXECUTIVE COMMITTEE POLICIES AND PROCEDURES
A.1 SCOPEThe Executive Committee (EC) oversees the development and evolution of the Java technologies within the JCP. A.2 MEMBERSHIPThe Executive Committee is composed of 16 Java Community Process Members plus a non-voting Chair. The Chair of the EC will be a member of the Process Management Office. The 16-voting members will be selected from Java Community Process Members. Sun Microsystems, Inc. will have a permanent voting seat on the EC. That Sun representative will not be a member of the PMO. No Member may hold more than one voting seat on the EC at any given time. For example, if a Member has majority-ownership of one or more other Members, then that group of Members can have only one seat on the EC at any given time. A.3 DUTIES AND RESPONSIBILITIES
A.4 EC SELECTION PROCESS AND LENGTH OF TERM
Voting Members on the EC serve 3-year terms. There are 10 Ratified Seats, 5 Elected Seats, and the permanent seat held by Sun Microsystems, Inc. The 3-year terms are staggered so that 5 of the 15 seats are normally up for ratification/election each year as follows:
The cycle repeats every 3 years. Ratified or Elected Seats that are vacated prior to completion of the term will be filled as described sections A.4.2 and A.4.3. A.4.1 RESIGNATION OF EC SEATSVoting Members on the EC may resign their seats at any time during their term. Should one voting Member on the EC acquire a majority ownership of another voting EC member, one of those members must resign his or her seat by the effective date of the acquisition. EC members who fail to remain Java Community Members forfeit their EC seat. A.4.2 SELECTION PROCESS FOR RATIFIED SEATSMembers are selected for the 10 Ratified Seats using a ratification ballot that is carried out starting the first week of October of each year. The table given at the end of section A.4 determines the number of Ratified Seats up for ratification each year of the 3-year cycle. A Ratified Seat that was vacated by resignation will be filled for the remainder of its term by a ratification ballot that will be held no later than two months after the resignation (unless the resignation is less than three months before the next scheduled ratification ballot). The ratification ballot is carried out as follows:
All Members are eligible to vote in a ratification ballot subject to the provision that if a Member has majority-ownership of one or more other Members, then that group of Members will collectively have 1 vote. A.4.3 SELECTION PROCESS FOR ELECTED SEATSMembers are selected for the 5 Elected Seats using an election process that is carried out starting the third week of October of each year. The table given at the end of section A.4 determines the number of Elected Seats up for election each year of the 3-year cycle. An Elected Seat that was vacated by resignation will be filled for the remainder of its term by an election ballot that will be held no later than two months after the resignation (unless the resignation is less than three months before the next yearly election). The election ballot is carried out as follows:
All Members are eligible to vote in an election ballot subject to the provision that if a Member has majority-ownership of one or more other Members, then that group of Members will collectively have 1 vote. A.5 EC VOTING RULESThe voting rules in this version of the JCP are as follows:
A.6 MEETINGS
A.7 FORMATION OF THE INTERIM EXECUTIVE COMMITTEE
APPENDIX B: REVISING THE JCP, JSPA, AND IEPA
Revisions to the Java Community Process (this document), the Java Specification Participation Agreement, and the Individual Expert Participation Agreement will be carried out using the Java Community Process with the following changes:
|