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

[Reinier Zwitserloot]

I thought the decision was made that only 1 underscore was allowed per set
of underscores in a number. i.e. legal:

0b1111_0000_1111_0_1_0;

not legal:

0b1111_____0000;

The spec as written allows any number of underscores.

I don't think it it matters much either way.

For consistency, < and > should remain separate tokens which implies writing
new ArrayList<>(); with funky spacing is perfectly legitimate. As has been
said, the compiler's job is not to enforce code style. Also, by leaving them
as separate tokens you can put comments inside which could be useful.

Introducing <> as a separate token in the future is not impossible if we
don't adopt <> as a singular token today; "new" "typename" "<>" will be
defined as an alternative syntax for the diamond operator, equal to "new"
"typename" "<" ">".

 --Reinier Zwitserloot



On Wed, Mar 9, 2011 at 4:00 PM, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> 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
> >>>>>>
> >>>>>>
> >
>
>
>