General community and Process Questions (blog comment followups)

[Ruslan Shevchenko]

> Hello.
>
>>  Hi all,
>>
>
> Many proposals sent into Coin were not well written and lacked
> prototypes.  While the string proposal in question was sent in early,
> went through several helpful iterations of refinement on the list, and
> laudably included a prototype implementation, in the end I thought the
> proposal provided limited benefits over the alternatives for the
> complexity it introduced.
>

 May be part of fault with multiline string proposal liew with me: I wrote
first version of multiline string proposal, without knowing about
analogical proposal of Steve Colebourne (which was relative well-knonw in
Sun, as I guess now); this fact potentially can provoke some social
issues.

(interesting, than later I found 6 different proposals, implementations or
warkarrounds on this subject, laying arround in blogs and mail-lists)

>From other side, I does not think that pre-final version of proposal was
badly-defined (
http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000747.html )
Especially, if we compare this with some of proposals, which were
accepted, like indexed access to collections
(http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001108.html)

Knowing, that coin proposals are not final decisions of all details, but
only entries for work of JSR expert group, I think that quality of
proposal (after some not-so-big barrier) was not a main factor of choice.
Extra complexity can be deleted on expert group stage.

Finally what to do next: I summarize all about multiline strings in Java
(http://docs.google.com/Doc?docid=0AX56ZsgNVurJZGhodmdncjhfMjFncjVzNGZoZw&hl=ru
) [with open issue about 'IDE-friendly' marker]
 and if will exists possibility to submit JSR only with a multiline
strings - I propose interesting parties coordinate (here or in any other
public place) and submit one, using this document as starting point.
[Difficult part is find somebody in Sun, familiar with JSR procedures to
participate].



>>  This leads to
>>
>>  b) What is the process for finalizing the changes that go into coin
>>  and then get folded into the jdk. I understand that people who
>>  participate here have some influence, but who has final say? Does the
>>  whole thing get wrapped up in a JSR and get voted? Is it just a
>>  judgement call of the internal Sun architects? Understanding the
>>  process would really help it feel more 'open' and I think get people
>>  psyched about contributing.
>

 ................
>
> coin contributions.  For example, back in May there was an open issue
> concerning the grammar changes needed for underscores in numbers [5].
> No one sent in a message on this matter until I sent in a grammar in
> July [6].   Neither the coin list nor readers on my blog caught the
> embarrassing but small mistake I made in the grammar [7].  In terms of
> difficulty of language evolution, this grammar change is easy.  Having
> taken an undergraduate class in compilers or automata theory is
> sufficient background to work on this, but no one else contributed a
> grammar for this despite presumed interest in the feature and the large
> number of coin subscribers.
>

 May be this shown, that interest to number literals is relative small ?