For further consideration...

[rssh at gradsoft.com.ua]

 I belive Sun (in face of Joe Darcy) have dictator right do any decisions
op proposal, just because  Java it's child of Sun, and does not exists and
contract duty on Sun decision making process about Sun product. Also I
think that if we have 40 proposal and can implement only 10, than some
valuable proposal be left and difference between accepted and rejected
proposal will be fully subjective.

I.e. this is Open Source. All service is AS-IS. If you don't like Java -
fork one (GPL allows this) or create other language (I guess most
subscriber of the list have own  languages)

But from other side, I will be happy to see some 'post-mortal' analysis of
project, i. e.
 - split proposal on two parts:
   - too vague or understable.
 - for understable proposals
   - Sun string anticipate this proposal (why ?)
   - Sun provide some guidelines for future work and resubmission
 (made coin-s regular, one-s a year ?)

Also I understand, that doing such post-mortal analysis is a lot of work, so
 I can only to ask something simular but do not require.





> 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
>
>