Joseph D. Darcy's Sun Weblog

Friday March 06, 2009

Project Coin: Week 1 Update

In its first week, Project Coin enjoyed a vigorous start with well over a dozen proposals submitted:

• Strings in switch, Joe Darcy

• Block Expressions for Java, Neal Gafter

• Improved Exception Handling for Java , Neal Gafter

• Automatic Resource Management, Josh Bloch

• Improved Type Inference for Generic Instance Creation, Jeremy Manson

• Improved Wildcard Syntax for Java, Neal Gafter

• Multiline strings, latest revision, Ruslan Shevchenko

• Use "default" keyword for default visibility, updated to use "package" instead, Adrian Kuhn

• Elvis and Other Null-Safe Operators, Written by Neal Gafter and submitted by Stephen Colebourne

• Simple Resource Clean-up, Roger Hernandez

• Import Aliases for Classes and Static Methods, Phil Varner

• Lightweight Properties, David Goodenough

• 'This' type, Marek Kozieł

• Static Methods in Interfaces, Reinier Zwitserloot

• fold keyword, Gabriel Belingueres

• Multiple switch expressions and case ranges, Pinku Surana

• Simplified Varargs Method Invocation, Bob Lee

Traffic on the the list has been high, with lots of feedback and analysis leading to some revised proposals.

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

• 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 these fronts.