Documentation of Project Coin features as implemented in the JDK 7 developer preview

[Mark Mahieu]

Somewhat perverse thought - would anyone want to write a comment in there, I wonder...

	List<Integer> percentages = new ArrayList</* 0-100 only, please! */>();


Mark


On 9 Mar 2011, at 15:00, Maurizio Cimadamore wrote:

> On 09/03/11 14:30, Rémi Forax wrote:
>> On 03/09/2011 03:17 PM, Maurizio Cimadamore wrote:
>>> On 09/03/11 13:49, Eamonn McManus wrote:
>>>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>>>>> diamond. The compiler should be fixed.
>>>> I don't understand this. We're not introducing a new lexical<>   token,
>>>> are we? So obviously the compiler must allow spaces between<   and>,
>>>> as between any pair of tokens. Stylistically, some people might prefer
>>>> to write List<   Integer>, say, and would certainly be surprised not
>>>> to be able to write List<   >.
>>> I think it would be better if the compiler would be stricter about this,
>>> and to deal with diamond as if it were a token - otherwise, programmer
>>> might abuse of current behavior:
>>> 
>>> new ArrayList<   >();
>>> 
>>> new ArrayList<
>>>> ();
>>> 
>>> Which is ugly.
>>> 
>>> Maurizio
>> It's not fundamentally different from
>> new ArrayList
>> <>
>> ();
>> which is legal.
> I see, so since the above is allowed, let's add a further level:
> 
> new ArrayList
> <
>> 
> ();
> 
> :-)
>> And considering<>  is a kind of new operator is weird.
>> 
> I haven't used the 'operator' word once in my earlier emails.
>> As Éamonn says new ArrayList<  String>  is legal so new ArrayList<  >
>> should be legal.
> As I said, I think that this argument can go both ways: one can think 
> that diamond is special enough to deserve special treatement; on the 
> other hand, one would like diamond to be uniform with standard type 
> argument lists. In my opinion, the benefits of treating '<>' as a single 
> token outweights the problems (at the end of the day, the only arguably 
> sensible thing that you couldn't do is 'Foo< >' - note the space).
> 
> Said that, all this is speculation - as Ulf pointed out, the spec is 
> explicitly allowing whitespaces inside diamonds (strange thing is that 
> doesn't seem to allow other separators... but I think that needs to 
> follow if '<' and '>' are separate tokens).
> 
> Maurizio
>> Rémi
>> 
>>>> Éamonn
>>>> 
>>>> On 9/3/11 2:25 PM, Maurizio Cimadamore wrote:
>>>>> On 09/03/11 12:57, Ulf Zibis wrote:
>>>>>> Why do you allow whitespace between the "<" and">" of a diamond.
>>>>> Good catch - I don't think this is a spec problem, as the grammar for
>>>>> diamond is defined as follows in the latest draft:
>>>>> 
>>>>> /TypeArgumentsOrDiamond:/
>>>>> 
>>>>>           /TypeArguments/
>>>>> 
>>>>>           |<||>|
>>>>> 
>>>>> 
>>>>> So it is more a compiler bug erroneously accepting spaces 'inside' the
>>>>> diamond. The compiler should be fixed.
>>>>> 
>>>>> Maurizio
>>>>>> Is whitespace allowed for ++ operator e.g.?
>>>>>> 
>>>>>> -Ulf
>>>>>> 
>>>>>> 
>>>>>> Am 09.03.2011 07:40, schrieb Joe Darcy:
>>>>>>> Joe Darcy wrote:
>>>>>>>> Hello.
>>>>>>>> 
>>>>>>>> I've posted documentation of the semantics of the Project Coin
>>>>>>>> features as implemented in the JDK 7 developer preview,  b130, at:
>>>>>>>> http://cr.openjdk.java.net/~darcy/ProjectCoin/ProjectCoin-Documentation-v0.83.html
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Before sending in comments or questions about a feature to coin-dev,
>>>>>>>> please read the discussion section after a feature.  Many design
>>>>>>>> considerations are discussed in those sections.  Additionally, some
>>>>>>>> known bugs in the current implementation are noted in the text.  In
>>>>>>>> particular, javac in the JDK 7 developer preview erroneously accepts
>>>>>>>> diamond combined with non-generic classes and accepts some uses of
>>>>>>>> diamond with anonymous inner classes. These bugs will be corrected in
>>>>>>>> future builds.
>>>>>>>> 
>>>>>>>> Happy reading,
>>>>>>>> 
>>>>>>>> -Joe
>>>>>>> No comments from the coin-dev readership on the posted documentation?
>>>>>>> 
>>>>>>> -Joe
>>>>>>> 
>>>>>>> 
>> 
> 
>