One of the most interesting things about Java is that developers take
things personally when someone trashes it. Take some time to look at
all those "Java is slow" or "Java is crap" posts at Slashdot. I find them very amusing - the replies are often somewhat intelligent, and often offer good substance and facts.
But that's not what I want to talk about in this post. I want to talk
about the other side of this: when the 1.5 features and language
changes started do be announced, the Java community got divided into
three main categories: those who like the changes, those who don't, and
those who won't spend their time fighting others about the m.
Personally, I'm on the "stop polluting my language" front, and I found
that most of the new language features are either good but not that
needed, or something that's just being thrown in the language for it to
look good on "Java versus C#" feature matrix comparisions.
I strongly feel that Java is starting to become something evolved, not
designed. Its age is starting to show. If you take a look at some '97
code, you'll see lots of Vectors, Hashtables and Enumerations hanging
around. If you look at '01 code, it has lots of getters/setters, Lists,
HashMaps. In '02 code, you can see usage of JavaDoc attributes to
define meta-data (XDoclet, QDox,
etc), and lots of XML parsing routines. So, what the future holds for
our everyday Java? Lots of genericized collections, funky iterations,
metadata and declarative programming everywhere? Methods with varargs
(the dreaded printf() syntax) and almost no typecasts?
Joshua Bloch gave two talks about this at thursday's BOF sessions at
JavaOne. One of the BOFs was about metadata facilities in the upcoming
release, and the other was about how the language features are going to
change our so dear Java API.
First, the metadata stuff. I think few of you have seen the syntax
proposed, as the draft spec is not out yet, so here's a sample:
@RequestForEnhancement(id=18230, author="Carlos Villela", summary="Refactor unused methods") public class Foo extends Bar implements FooBar { public @Transaction void doStuff() { //... } }
At a first glance, this looks awful to lots of people. But, in fact, it's an interesting change to the syntax:
Joshua explictly said that if metadata definition was there since
Java's day 1, we probably wouldn't have 'strictfp', 'synchronized' or
'transient' keywords, as they're only used at runtime to determine a
specific semantic for the method/field being accessed. Indeed, very
interesting, but why not make this change now? Why can't we deprecate a
keyword and suggest the use of the attribute instead?
This way, instead of polluting the language with even more syntax,
we're removing keywords in order to promote a more generalistic
approach, that is, IMHO, much better. Joshua also said that they're not
adding new keywords anytime soon, and I think that's fair enough - if
they at least put "adding new keywords" in the same category as "adding
new symbols".
Tiger comes with A LOT of new
symbols, or new meaning for some symbols: now < and > mean
different things when used with generic types. '.' means different
things if used with varargs ('...' means 'this is a variable-length
array of parameters'). ':' now can be used in the enhanced for loop (it
was used before in labels), and so on.
Previous Topic
