JDK Enhancement-Proposal & Roadmap Process -- DRAFT

[Stuart Marks]

Hi Mark,

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: ensure that all Throwable subclasses 
in the JDK have at least the standard set of constructor overloads, including 
no-arg, message, cause, and (message, cause).

(Obviously I'm not interested in discussing the merits of this proposal at this 
point; this is merely an example of a horizontal change.)

The point of this proposal is that it wants to establish a global property over 
all Java SE APIs. It's pretty easy to find examples in different parts of the 
system that don't conform (see java.rmi.server.ServerNotActiveException and 
java.awt.FontFormatException to name just two).

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

By the way, I don't think this example is a special case. The Coinification 
work I did in JDK 7 (upgrade library code to use diamond, upgrade library code 
to use try-with-resources, etc.) is another example of a horizontally-oriented 
project. I also have several others in my back pocket. :-)

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.

Thanks.

s'marks