Opportunity Cost and Proposal Selection

Joe Darcy Joe.Darcy at Sun.COM
Tue Mar 31 18:58:07 PDT 2009


There has been some traffic on the list about criteria for proposal 
selection (and non-selection) and I wanted to discuss that briefly.

First, a reminder from some earlier blog entries describing the context 
for Project Coin:

"Especially with the maturity of the Java platform, the onus is on the 
proposer to convince that a language change should go in; the onus is 
not to prove the change should stay out."
December 23, 2008

"Given the rough timeline for JDK 7 and other on-going efforts to change 
the language, such as modules and annotations on types, only a limited 
number of small changes can be considered for JDK 7."
December 11, 2008

With nearly 70 proposals submitted to the mailing list and the Sun bug 
database having well over 100 open "requests for enhancements" (rfe's) 
for the language, the large majority of those proposals and rfe's will 
*not* be included in JDK 7 as part of Project Coin or any other effort.

Project Coin will be limited to around 5 proposals total.  That's it.

Therefore for Project Coin, in addition to determining whether a 
proposal to change the language is in and of itself appropriate, a 
determination also has to be made as to whether the change is more 
compelling than all but four or so other proposals.

In economic terms, there an an opportunity cost in the proposal 
selection; that is, because of finite resources, choosing to have a 
particular proposal in the platform removes the opportunity to do other 

There will be good, compelling proposals that would improve the language 
*not* selected for Project Coin because there are a full set of better, 
more compelling proposals that are more useful to include instead.

Having available prototypes for proposals, running the existing tests, 
and writing new tests can only better inform the forthcoming proposal 
evaluation and selection.


More information about the coin-dev mailing list