Re: Java language and library suggestions
Lew wrote:
markspace wrote:
http://blogs.sun.com/darcy/date/20090331
There are some amazingly bad suggestions there. For example, the
proposal to allow "#switch (...) instanceof" is ludicrous. Others look
all right on the face of them, such as "open and close brace optional
for single statement try, catch, finally, method declaration", but then
we would just mandate to put the braces back in by convention just like
we do now for 'if' and 'for' and such. Others make sense to me, like
"Allow the class literal of the surrounding class to be referenced with
the 'class' keyword".
"Underscores in numbers" is another stupid one.
I'm sure others have similar reactions, with different suggestions
plugged into "ludicrous", "plausible but not really" and "good idea"
from mine.
That was just a proposal list, some of which are woefully
underspecified. It seems the strongest contenders were the first ones
which were passed, namely Strings in switch (there are some cases where
that's useful), the catch-multiple exceptions, ARM (that is probably
going to be the real Java 7 killer feature), shortening generic
construction (slightly hellish for compilers, I suppose), null-safe
operators (which generated strong opposing positions), and apparently
generics+varargs savory goodness.
Note that all of these are for further consideration, which seems to me
to be mostly "projects that would likely be more beneficial than not and
which have clear specifications" as opposed to "projects that will be
making it into Java 7".
I'd say the projects most likely to make it in are the catch-multiple,
ARM, and generics goodnesses: all of these are very clear-cut,
compiler-level changes that have very demonstrable use cases and little
opposition.
The safe-null-check operators can be confusing and misleading at times
for the unwary users, and Strings in switch is in the apathetic center.
A lot of the second round picks have some extreme polarizations in view;
probably the easiest one there is the binary literal type, which
requires minimal changes to the lexer.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth