The language talks at JavaOne had a good attendance. At first you may feel “geez, how about getting real security in EJBs … that is more important than a damn for shortcut”. But these things do matter.
I have been involved in many communities, and maybe none like the Perl community. Since they are lead by a linguist (Larry Wall), the language is very different. You may say that it is too complicated, too easy to make it look like line-noise, etc…. but has two characteristics:
- Fun: You can do things how you want, and have fun trying to do weird things [yes, this may not lead to the best code ;)]
- Restricted: You do not feel at all restricted with this language. You can do things however YOU want [again, maybe not the best idea for the masses
For me, items like a simple foreach construct help a lot.
Now code like Cedric’s and Cameron’s go from:
public boolean containsAll(Collection c) {
for(Iterator iter = c.iterator(); iter.hasNext();) {
if (!contains(iter.next()) {
return false;
}
}
return true;
}
to:
public boolean containsAll(Collection c) {
for (Object o : c) {
if (!contains(o)) return false;
}
return true;
}
Not a BIG deal sure, but a bit cleaner none the less. Then you get to nested loops like:
List deck = new ArrayList(52);
for (Suit suit : Suit.VALUES)
for (Rank rank : Rank.VALUES)
deck.add(new Card(suit, rank));
Collections.shuffle(deck);
and you see the beauty come through (and it just works… no chance to screw up a “i.next();”.
I may have prefered to have foreach as a keyword here (or even like Perl where you can use either), but again, that isn’t a HUGE deal to me. I do worry more about adding “enum” as a keyword, as how many times have you done: Enumeration enum = …; (Rickard has pointed out).
Along with Generics, Enums, Autoboxing, metadata, and the rest… 1.5 will be a brave new world. I know it will take awhile to get here, and will take even longer to work out how best to use things like metadata… it has brought back some fun to our language. Let’s keep it coming.
funny
It's hard for me to imagine anything less important than EJB security or more important than making developer more productive ;-)
nice :)
How true. These changes are at the heart of the language so will change how everyone works (if they want to use them).
The EJB security was just what I kept hearing people shout about in the EJB BoF's at JavaOne ;)
Java grows up
I'm glad I'm not the only person who finds these things exciting. For me this is Java as a language growing up.
It's interesting to compare the evolution of Java with C++. The C++ crowd seemed to focus a lot on getting the core language right, at the expense of standard libraries. Java seems to have done things the other way round.
Having recently had the displeasure of working with some legacy C++ code recently, I have to say I prefer the Java approach. Libraries are key to getting work done whereas many language features are, perhaps surprisingly, not so important. Now the Java library is mature I feel it's a good time to address the issues in the language itself.
Ian.
nice :)
Yah, it's really too bad about EJB, so much developer productivity flat-out wasted, down the drain, that we'll never get back.
But what we do have is a ton of overly complicated & difficult to maintian web applications.
Maybe this was the purgatory java had to pass through to be considered a "serious" business application language. That's the only positive way of looking at it that I can think of.
Hmm..
I think that one of the points of Cedrics "break" was that it would be clear then that you didn't want the collection to iterate over all the elements if it found a match beforehand.
Say, I write the code as
public boolean containsAll(Collection c) {
boolean result = true;
for(Iterator iter = c.iterator(); result && iter.hasNext();) {
result = (result && contains(iter.next()));
}
return result;
}
Which really shows that what you wanted to do was while :).
I don't think there's a way to express this condition in the current foreach implementation, so you have to break out of the loop explicitly.
Which is good or bad, depending on how you look at it :).
Regards,
Vlad
Hmm..
Perhaps there's something against the following code, but I think it shows the intent very well:
public boolean containsAll(Collection c) {
for( Object o : c ) {
if( !contains(o) ) {
return false;
}
}
return true;
}
neater containsAll()
You can already say, if you don't mind taking an Iterator instead of a Collection:
boolean containsAll(Iterator i)
{
return
!i.hasNext()
||
(contains(i.next()) && containsAll(i));
}
Hmm..
I agree - but I think Cedric's point was whether we know what the original code's point was.
Off topic:
This is not a big problem here, but I just don't like too many returns in the code. Consider a situation where the loop is wrapped in a try/catch/finally. Then, does the author (or whoever is fixing the code) know that the finally will be still called? And when it will be called relative to the evaluation of the return? I've seen few really nasty bugs caused by things like that and that's what persuaded me that in t/c/f block the only right place for return is outside.
Regards,
Vlad