Plan B
Missing in Java SE 7: Simplicity
First, it was Closures. (If you do not understand the proposal after 2 reads, fret not - you aren't dumb. Its just that you deserve a simpler alternative.) And now its the Properties syntax that's taken center stage. We might next have a language extension where a special syntax like "<%$$%>" will make the runtime play a random MP3 from your favorite playlist. Cool, huh?
I couldn't agree more with Dan Creswell. Why is it hard to understand whether developers really need language extensions, new libraries or simply better IDE support? And what is most worrisome is the (apparent) difficulty that the silent majority of the Java community has in drawing attention to the increasing complexity of the Java language. At a time when Java newbies still struggle to understand generics, we're involved in an arms race with other languages to cram as many new "features" as possible. Is the community clamoring for these features? Has anyone bothered to ask? At this rate, what we'll need to decipher Java code is not an IDE, but this.
Honestly, I'd be tempted to stick to Java SE 6 (and not upgrade to 7 in the next decade) in order to escape the mindless complexity.
Planet earth calling JCP. The power of Java lies in its simplicity. Don't kill it. Can you hear me?
Posted at 08:56PM Feb 01, 2007 by Bharath Ravikumar in Java | Comments[4]
Posted by Mikael Gueck on February 01, 2007 at 11:33 PM IST #
If you do not understand the Java Language Specification after 2 reads, you're not dumb. You should instead read a document intended for learning the language, not a formal specification. For closures, I suggest you start here: http://www.bejug.org/confluenceBeJUG/display/PARLEYS/Closures+for+Java
Has anyone bothered to ask? Yes, actually. Repeatedly
At JavaPolis, on Java.net, and on Java.net again.
Posted by Neal Gafter on February 02, 2007 at 01:38 AM IST #
I completely agree. The Java language isn't much behind C++ in complexity today. People complain about C++ idonsyncracies and now Java too has a truckload of them. The greater-than-500 page Java generics FAQ: "Why doesn't this work, why doesn't that work", says it all. Light of heaven - its a 500 page FAQ on a language feature - bigger than the language spec itself.
As a part-time C++ programmer, who has learned to accept the complexity of templates in order to reap the higher order programming model they offer, I find the Java generics implementation to be horrendously complex with the only advantage offered being that of a simplified type cast. I can accept complexity, but generics as they stand now in Java 5, completely fail the complexity budget - the cost is too high for the trivial benefit offered. Hell, even Ken Arnold agrees.
I consider autoboxing (the way its implemented) as a mistake - see the HUGE Javalobby discussion on this code snippet which fails the expected behaviour:
Yes, you can complain to the effect that the == is not meant to be used that way..you must use the .equals method...try and explain that to a newbie programmer..and then tell him its ok when the objects are Enums.
2007-08 will be the year the "Java Gotchers", "Java Pitfalls" and other books of that genre will begin to get released - The language will inevitably get the label of being extremely complex and that will spell the beginning of the drop in the language adoption rate . Its kind of ironic really ... Stroustrup himself predicted that this would be the case early in 2000.
I think the runtime is here to stay for a very long time though. I think much of future development will move away from Java and instead use languages that target the JVM.
Posted by Tarun Elankath on February 02, 2007 at 05:42 PM IST #
I think, "The power of Java lies in its simplicity." is one of the most useless arguments in the history of programming in Java. Java is not simple. Java not even is good readable and understandable, maybe at max be at a mediocre level.
Ever used Smalltalk? No? But I bet you can simply understand what the following line of code would do:
Smalltalk is simple, because everything is an Object, all operations are method calls, and there are about 6 control structures for assignment, method call separation, local and temporary variables, and returning from a method (forgive me, if I forgot one, it's quite a time).
Btw., the above example uses closures (a.k.a. Blocks in Smalltalk). They are provided as parameters to the method ifTrue:ifFalse of the Boolean instance that got built from the comparison. As Neal mentioned, no one learns Java from reading its specification. A proposal has to write down the specification, though. Once having a tutorial, it's easy to learn. And for the biggest advantage I see, it provides means to add new features as API rather than new language constructs. If it weren't too late, one should drop the for-each loop and extend the Collection API for taking closures.
In contrast to closures, the introduction of properties would only serve few specific domains of applications. Such constructs don't belong into a language layed out for general use and obviously can better be solved by focused APIs and IDE support. This is a point, were I agree.
As a summary, I'd say "The power of Java lies in its generality."
Posted by Stefan Schulz on February 04, 2007 at 05:20 PM IST #