JEP 2: JEP Template

AuthorMark Reinhold
Discussiondiscuss at openjdk dot java dot net
// JDK Enhancement Proposal ("JEP") template v1.0
// ==> Delete all lines starting with "//" and all unused header lines
//     before circulating, posting, or submitting a proposal
// Instances of this template are meant to be evolving documents.  When
// you initially draft a JEP you don't need to fill out every section of
// the template, and in fact at that point you probably won't be able to
// do so.  As you get feedback and build consensus around your proposal
// you'll revise the JEP accordingly.  If your JEP is accepted and funded
// then you'll continue to revise it as the work progresses so that, once
// it's complete, the JEP can serve as an authoritative record of what
// was actually done.
// An instance of this template describes what is being proposed, and
// why.  It does not include project-management information such as
// detailed completion estimates, task lists, integration requirements,
// etc.; that type of information will be managed separately.
// To submit a JEP for posting send a completed version of this template
// in e-mail, as a text/plain attachment, to jep dash submit at openjdk
// dot java dot net.
// ------
// These lines must be at the very top of the file, with no blank lines
// until the line after the last header item.  Some items are REQUIRED;
// all others are optional.
// Short descriptive title of the proposal -- REQUIRED
Title: Pluggable API for dynamic service-oriented buzzword compliance
// Author's full name (no e-mail address) -- REQUIRED
Author: Pierre Chang
// Employer or affiliated organization, if any
Organization: Dharma Initiative
// Owner's full name (no e-mail address) -- REQUIRED, if the person now
// responsible for this JEP is not the Author
Owner: Stuart Radzinsky
// Date initially created -- REQUIRED, in YYYY/MM/DD format
Created: 2004/8/15
// Type of proposal -- REQUIRED, one of:
//   Feature -- A feature intended eventually for a JDK Release Project
//   Research -- A research effort rather than a product deliverable
//   Infrastructure -- A proposal to provide or enhance infrastructure
//   Informational -- Non-normative information of general interest
//   Process -- A new or revised development process or guideline
Type: Feature
// Process state -- REQUIRED, one of:
//   Draft, Posted, Submitted, Candidate, Funded, Completed,
//   Active, Withdrawn, or Rejected
State: Draft
// Exposure -- REQUIRED, either "Open" or "Closed"
Exposure: Open
// Component affected, REQUIRED for Feature JEPs
// We use two-part identifiers of the form <area>/<component>.
// The areas are: vm, core, client, web
// The components depend upon the areas, as follows:
//    vm: comp, gc, rt, svc
//    core: lang, libs, i18n, net, sec, svc
//    client: gui, sound
//    web: jaxp, jaxb, jaxws, corba
// A proposal for a new garbage collector, e.g., would go in "vm/gc",
// while one for a new networking protocol would go in "core/net".
// Use "--" for the component name if more than one component in an area
// is significantly affected, or if some component not listed here is
// affected.
// Use "--/--" for the value of this header if more than one area is
// affected, e.g., for a proposal to restructure the build process.
Component: core/libs
// Scope of the proposal -- REQUIRED only for Feature JEPs, one of:
//   SE -- Java SE APIs or other interfaces modified or extended;
//         might also include changes to JDK-specific APIs or interfaces
//   JDK -- JDK-specific APIs or other interfaces modified or extended
//   Impl -- No supported APIs or interfaces are affected
Scope: JDK
// If this JEP will have a JSR then include this line and insert its
// number.  If this JEP is expected to have a JSR but the JSR is not yet
// approved as such in the JCP then write "TBD" for the number.  If this
// JEP will be part of a Maintenance Review of an existing JSR then insert
// its number followed by "MR", e.g., "JSR: 221 MR".  Do not include this
// line if this JEP describes a small enhancement that will be covered by
// a Platform Umbrella JSR.
JSR: 999
// List the primary RFE associated with this JEP, if any,
// on this line.  Additional related RFEs may be listed in parentheses,
// separated by commas.
RFE: 4040458 (2718281, 3141354)
// Mailing list for discussion of this JEP -- REQUIRED
Discussion: buzz dash dev at openjdk dot java dot net
// Suggested start date, in the format <year>/Q<quarter>
Start: 2012/Q3
// Other JEPs upon which this JEP depends, either draft names or JEP
// numbers
Depends: 4815, 1623
// Other JEPs that depend upon this JEP, either draft names or JEP
// numbers
Blocks: 4200
// Rough effort estimate, one of:
//   XS -- Less than one developer-month (20 working days)
//   S  -- Less than three dev-months
//   M  -- Less than six dev-months
//   L  -- Less than one dev-year
//   XL -- More than one dev-year
Effort: XS
// Rough duration estimate, one of:
//   XS -- Less than one month (calendar)
//   S  -- Less than three months
//   M  -- Less than six months
//   L  -- Less than one year
//   XL -- More than one year
// The duration reflects the calendar time needed to complete the
// proposed work.  It can be more or less than the effort estimate.
Duration: S
// Version of the template used to create this proposal -- REQUIRED
Template: 1.0
// References to organization-internal documents, of the form
// <orgname>:<string>
Internal-refs: Yoyodyne:554983, Oracle:A360:654321
// Full names of the reviewers of this proposal, comma-separated
Reviewed-by: Mikhail Bakunin, Miles Straum
// Full names of the Group and Area Leads who endorse this proposal
Endorsed-by: James LaFleur, Horace Goodspeed
// Names of the organizations and/or individuals who commit to doing all
// of the work necessary to implement this proposal, including not just
// development but QA and TCK test development, and documentation
Funded-by: Yoyodyne Inc.
// -------------
// The body of the proposal itself uses the Markdown markup language
// (  It must be
// separated from the header by at least one blank line.
// All sections are optional except those marked REQUIRED.  Please keep
// sections in the order shown below.  Please use lines of dashes under
// section titles rather than "##"-style prefixes, which are less
// readable.


// REQUIRED -- Provide a one-paragraph summary of the proposal, no more
// than a few sentences.  This summary will be rolled up into feature
// lists and other documents, so please take the time to make it short
// and sweet.


// What are the goals of this proposal?  Omit this section if you have
// nothing to say beyond what's already in the summary.


// Describe any goals you wish to identify specifically as being out of
// scope for this proposal.

Success Metrics

// If the success of this work can be gauged by specific numerical
// metrics and associated goals then describe them here.


// Why should this work be done?  What are its benefits?  Who's asking
// for it?  How does it compare to the competition, if any?


// REQUIRED -- Describe the enhancement in detail: Both what it is and,
// to the extent understood, how you intend to implement it.  Summarize,
// at a high level, all of the interfaces you expect to modify or extend,
// including Java APIs, command-line switches, library/JVM interfaces,
// and file formats.  Explain how failures in applications using this
// enhancement will be diagnosed, both during development and in
// production.  Describe any open design issues.
// This section will evolve over time as the work progresses, ultimately
// becoming the authoritative high-level description of the end result.
// Include hyperlinks to additional documents as required.


// Did you consider any alternative approaches or technologies?  If so
// then please describe them here and explain why they were not chosen.


// What kinds of test development and execution will be required in order
// to validate this enhancement, beyond the usual mandatory unit tests?
// Be sure to list any special platform or hardware requirements.

Risks and Assumptions

// Describe any risks or assumptions that must be considered along with
// this proposal.  Could any plausible events derail this work, or even
// render it unnecessary?  If you have mitigation plans for the known
// risks then please describe them.


// Describe all dependences that this JEP has on other JEPs, components,
// products, or anything else.  Dependences upon other JEPs should also
// be listed in the "Depends:" header at the top of the file.
// Describe any JEPs that depend upon this JEP, and likewise make sure
// they are listed in the "Blocks:" header at the top of this file.


// How will this work impact other parts of the platform, the product,
// and the contributors working on them?  Omit any irrelevant items.

  - Other JDK components: ...
  - Compatibility: ...
  - Security: ...
  - Performance/scalability: ...
  - User experience: ...
  - I18n/L10n: ...
  - Accessibility: ...
  - Portability: ...
  - Packaging/installation: ...
  - Documentation: ...
  - TCK: ...
  - Other: ...