Project Coin so far, suggestions for refining current proposals and improving new ones

[Joseph D. Darcy]

Greetings.

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 
sent in.

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"
    http://blogs.sun.com/darcy/entry/criteria_for_desirable_small_language

    "Guidance on measuring the size of a language change"
    http://blogs.sun.com/darcy/entry/guidance_measure_language_change_size

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, [1], for the 
admittedly simple strings in switch change provides adequate detail on 
these fronts.

-Joe

[1] 
http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000001.html

PS I've reconfigured the list to accept HTML messages.  To get an HTML 
message through, just send HTML, not HTML and text.