Java’s Fear of Commitment
People Over Process » Java’s Fear of Commitment Java is a general purpose, object oriented programming language. It’s roots in early 90’s object oriented theory, more importantly, the desires and goals of that theory can’t be overlooked when asking why Java is the way it is. The culture of Java design is to push out commitment to a given way of doing things (an “implementation”) as much as possible. In Java culture, dependencies, esp. conceptual ones, are nasty and to be avoided. They’re taboo, even.
The problem with Java ... is not with Java.
To over-simplify - as skill increases, programmers learn increasingly useful abstractions - procedures, objects, classes, metaprogramming, etc. The final lesson is to learn minimalism - how to solve a problem in the simplest and clearest fashion possible. Most programmers make it only part way up the curve.
Repeating what I have said before:
Xen, Java and Web Hosting PHP - the most commonly available alternative - has a low threshold for entry for new programmers, and the resulting works largely reflect this. Lots of projects get started, generate early/flashy results, then bog down. Look inside and you find the code is a mess. Pretty much what you would expect from new, enthusiastic programmers with limited skills. (Admittedly I wasn’t impressed with the internals of the PHP interpreter either). PHP is good for small/simple webapps, but beyond that is less desirable (my opinion).
Java projects tend to have a different malady. The threshold for entry with Java is a bit higher, and requires that you understand abstractions. Perhaps not surprisingly, the quality of Java code tends to be higher, with the common failing of too many abstractions. Occam’s Razor: Do not multiply concepts beyond necessity - could be more often applied in the Java world (about which Bruce Tate has written well).
Java is a wonderful base for a skilled programmer. Java is efficient and eloquent - with only the less-mature .NET platform as a challenger. Java does not require you to use extraneous abstractions - though it certainly makes them easy to write. The Java community offers a flood of abstractions - some useful, and some less useful. You simply need to exercise good taste in chosing what to adopt in you projects and personal practices.