JEPs 1 & 2: Interaction of JEPs with JCP

[Dan Smith]

JEPs 1 & 2 present an unclear picture of how JEPs interact with the JCP.

From JEP 1:

> If a proposal accepted into this process intends to revise existing standard interfaces, or to define new ones, then a parallel effort to design, review, and approve those changes must be undertaken in the JCP, either as part of a Maintenance Review of an existing JSR or in the context of a new JSR.

The "parallel effort" referred to seems to be external to the JEP itself.

> It’s up to Group Leads, Area Leads, and the OpenJDK Lead to ascertain whether sufficient Committers and other Contributors have signed up to do all of the work required to complete a JEP so that it may considered to be funded. This work includes not just design and implementation but also, as appropriate, QA test development, TCK test development, documentation, and any other activities that might be necessary.


Here, TCK test development is considered part of the "work required to complete a JEP".  "Documentation" or "other activities" might be interpreted to mean a JCP specification, if we're viewing the JCP effort as part of the JEP.  This seems inconsistent with the "parallel effort" view.

From JEP 2:

> // 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

Here's the most concrete problem: is the effort to run a JSR, produce a specification and TCK, etc., part of this estimate or not?

> // 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.

If the JSR is not part of the JEP: does this timeline include the full JSR timeline? or is it better to think of the JEP as a prototype feature that can be completed and later standardized/tweaked by a JSR?

> Dependences
> -----------
> 
> // 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.

It might make sense to list the JCP as a thing that depends on this JEP.  Or are "depends on this" dependencies supposed to be restricted to just other JEPs?  (After all, the set of things that depend on any particular JEP is unbounded.)

> Impact
> ------
> 
> // 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: ...

Or maybe it makes sense to list the JCP here...

It's unclear to me whether this is a list of things that are _part of_ the JEP, or external things that _interact with_ the JEP.  I note that "TCK" is on the list, but I'm not sure how to interpret it.

—Dan