For further consideration...

[David Goodenough]

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.  It does make
the decision making process appear somewhat arbitrary.

David