For further consideration...

[Joseph D. Darcy]

David Goodenough wrote:
> On Wednesday 25 March 2009, David Goodenough wrote:
>   
>> On Tuesday 24 March 2009, Joe Darcy wrote:
>>     
>>> Greetings.
>>>
>>> In the first three weeks  of Project Coin over two dozen proposals have
>>> been sent to the mailing list for evaluation. The proposals have ranged
>>> the gamut from new kinds of expressions, to new statements forms, to
>>> improved generics support.  Thanks to everyone who has sent in
>>> interesting, thoughtful proposals and contributed to informative
>>> discussions on the list!
>>>
>>> While there is a bit less than a week left in the call for proposals
>>> period, there has been enough discussion on the list to winnow the slate
>>> of proposals sent in so far to those that merit further consideration
>>> for possible inclusion in the platform.
>>>
>>> First, Bruce Chapman's proposal to extend the scope of imports to
>>> include package annotations will be implemented under JLS maintenance so
>>> further action is unnecessary on this matter as part of Project Coin.
>>> Second, since the JSR 294 expert group is discussing adding a module
>>> level of accessibility to the language, the decision of whether or not
>>> to include Adrian Kuhn's proposal of letting "package" explicitly name
>>> the default accessibility level will be deferred to that body.  Working
>>> with Alex, I reviewed the remaining proposals.  Sun believes that the
>>> following proposals are small enough, have favorable estimated reward to
>>> effort ratios, and advance the stated criteria of making things
>>> programmers do everyday easier or supporting platform changes in JDK 7:
>>>
>>>      * Strings in switch, Joe Darcy
>>>      * Improved Exception Handling for Java, Neal Gafter
>>>      * Automatic Resource Management, Josh Bloch
>>>      * Improved Type Inference for Generic Instance Creation,
>>>        Jeremy Manson
>>>      * Elvis and Other Null-Safe Operators,
>>>        Written by Neal Gafter and submitted by Stephen Colebourne
>>>      * Simplified Varargs Method Invocation, Bob Lee
>>>
>>> As this is just an initial cut and the proposals are not yet in a form
>>> suitable for direct inclusion in the JLS, work should continue to refine
>>> these proposed specifications and preferably also to produce prototype
>>> implementations to allow a more thorough evaluation of the utility and
>>> scope of the changes.  The email list should focus on improving the
>>> selected proposals and on getting any remaining new proposals submitted;
>>> continued discussion of the other proposals is discouraged.
>>>
>>> The final list of small language changes will be determined after the
>>> call for proposals is over so proposals sent in this week are certainly
>>> still in the running!  The final list will only have around five items
>>> so it is possible not all the changes above will be on the eventual
>>> final list.
>>>
>>> -Joe
>>>       
>> I realise that as you say the list is not final, but looking at the list of
>> items my lightweight properties proposal is (at least to my eyes)
>> considerably smaller than most of the provisional list.  It is smaller
>> in respect to all of the changes to the language, the changes to the
>> library and the changes to the compiler.
>>
>> I realise that anything mentioning properties is mired in history and
>> that there seems to be a "do it all or don't touch it" approach to the
>> problem which is a problem because the result is that it will not happen
>> for (to be realistic) at least 5 years.
>>
>> I also realise that the proposal is perhaps not written with detail updates
>> to the JLS etc, but I have never been involved in such things and would
>> hesitate to try to write them up properly.  If this is needed then I am
>> sure it can be done.  I am more than happy to work with anyone prepared to
>> give constructive help.
>>
>> I would therefore be interested to know why my proposal is not being
>> considered.  I believe I have shown need (BeanBindings, Criteria and
>> PropertyChangeSupport uncheckable string literals for field names).
>> It is also in the spirit of Java and one of great strengths (compiler/ide
>> checkability).
>>
>> David
>>     
>
> It is a shame that no-one has seen fit to reply to this note.

Especially since there has been no other recent traffic on the list to 
read or respond to!

-Joe