Project Coin so far, suggestions for refining current proposals and improving new ones
Joseph D. Darcy
Joe.Darcy at Sun.COM
Wed Mar 4 23:05:04 PST 2009
After a few short days, Project Coin has already received over 10
proposal submissions! Thanks for the insightful feedback and analysis
that has been occurring on the list.
A few general comments on the proposals that have been sent in so far to
help refine those proposals and improve future proposals before they are
The proposals submitted to Project Coin should already be well
thought-through. The goal is to have in short order specifications
approaching JLS quality, preferably with a prototype to help validate
the design. The feedback on the list should be much closer to finding
and illuminating any remaining dark corners of a proposal rather than
fleshing out its basic structure. If a proposal does not cite chapter
and verse of the JLS for parts of its specification, that is a good
indication the proposal is too vague. All affected sections of the JLS
should be listed, including binary compatibility and the flow analysis
in definite assignment.
It is fine if someone posts to the list to solicit help writing a
proposal for a given change.
Proposal writers should be aware of the size and scope parameters
established for the project; for background see
"Criteria for desirable small language changes"
"Guidance on measuring the size of a language change"
Also, proposal writers should search Sun's bug database for bugs related
to the change. The URL for the database is http://bugs.sun.com; Java
specification issues are in category Java SE and subcategory
specification. Of course the database is also searchable with your
favorite search engine restricted to that site. Besides the evaluation
field from the bug database, the external comment can often also have
valuable insight into and discussion of alternatives to solving the
problem or reasons why the problem shouldn't be solved.
As has already been happening on the list, authors and advocates of a
proposal are responsible for responding to feedback and incorporating
changes into any subsequent iterations of the proposal. For now, I
think it is adequate to just send the revised proposals to the list.
Only if there turns out to be frequent change would a more formal
tracking system be warranted. Keeping such discussions on the list is
important both to allow easy, centralized tracking of the proposal
drafts and also for future language archaeologists who are curious about
why a particular decision was made.
After a few iterations of feedback and refinements, the specification
and compilation strategy should be sufficiently detailed to provide
high-confidence that the proposal is practical and can be reduced to
practice. For example, I think the initial proposal, , for the
admittedly simple strings in switch change provides adequate detail on
PS I've reconfigured the list to accept HTML messages. To get an HTML
message through, just send HTML, not HTML and text.
More information about the coin-dev