JDK Enhancement-Proposal & Roadmap Process -- DRAFT

[mark.reinhold at oracle.com]

2011/6/28 12:17 -0700, stuart.marks at oracle.com:
> I have a question about how the process, and specifically the proposal
> template, deals with changes of a "horizontal" or "cross-cutting" nature. From
> the template,
> 
>> - Proposal template
>> http://cr.openjdk.java.net/~mr/jep/jep-template
> 
> there is a fairly specific hierarchy of areas and components:
> 
> // 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
> 
> This scheme lends itself well to enhancements in a specific component, as most
> enhancements are. But there's a different kind of enhancement that doesn't seem
> to fit well into the area/component form.
> 
> Consider the following example proposal: ...
> 
> A proposal like this doesn't seem to fit into a single area/component. It seems
> unreasonable to require multiple similar proposals for different
> components. I'm not sure of a good alternative though. Maybe we create a new
> pseudo-component or even pseudo-area to indicate proposals of a horizontal
> nature. Or perhaps we just say core/* or even */* (though the latter does seem
> unlikely).

That's actually the idea.  Further down in the draft template [1] it says:

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

On reflection the traditional glob symbol '*' makes more sense, so I'll
change the template to use that.

> By the way, I don't think this example is a special case. ...

Agreed.

> Another minor concern I have is the actual breakdown of components in the core
> area. Consider things like io, nio, and rmi. Do they fit into libs and net, or
> are they their own components? This isn't really a big deal; we just need to
> make sure we've established the right set of items in the area/component
> hierarchy.

I think the above structure is a reasonable starting point.  It isn't
cast in stone.  I expect the set of areas and (more likely) components to
evolve (slowly) over time.  If absolutely necessary we can always go back
and re-categorize old JEPs if the structure changes significantly.

- Mark


[1] http://cr.openjdk.java.net/~mr/jep/jep-template