JDK Enhancement-Proposal & Roadmap Process -- DRAFT
stuart.marks at oracle.com
Tue Jun 28 19:17:07 UTC 2011
I have a question about how the process, and specifically the proposal
template, deals with changes of a "horizontal" or "cross-cutting" nature. From
> - Proposal 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
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.
More information about the discuss