With Java, Simplicity and Productivity are Relative

Posted on March 8, 2010

0


*** A mashup of saved e-mails haphazardly put together follows. Warning, typos minefield ***

CC-by-SA

This is one argument I’ve seen in many incarnations. I have heard them a couple of times (bold text to highlight the hyperbole): Java is a very elegant language that allows simpler approaches to software development and better productivity levels than any other framework

Uhmmm, me no think so. I love Java. I work with it. But c’mon. Let’s be real if just by a little bit.

Let’s consider for example the overabundance of competing, sometimes incompatible APIs and frameworks for providing solutions to similar problem domains. This is almost non-existent in other languages. Why is this so relevant?

Well, for starters, there is no argument in that Java – by itself – is a simple language that one can learn and be proficient with in a matter of weeks, if not days. However, being proficient in Java development requires the learning of multiple APIs and frameworks. Let’s also consider what some (my favorite weasel word), but not all consider a problem: the incredibly large, deep package structures and almost linear class hierarchies both in Java and in existing APIs and infrastructures.

At first, the idea of the interface might have been a good one, and a major step forward from what we generally had available back in 1995. However, looking back, a multiple inheritance mechanism safer than the one in C++ (or a Mixin mechanism similar Scala traits) would have served us better in terms of productivity and object-orientation.

But when you have lemons, you make lemonade. Interfaces are an improvement over direct implementation inheritance… with the caveats that interfaces cannot change once they are widely used. Once you have an interface set, it is cast in stone. It can’t change, not without forcing every single class extending from it or one of its sub interfaces. This is not a feasible proposition for large systems, or for products that are meant for consumption by external parties.

But this is incredibly minor compared to what I consider major blunders in the language.

  1. Lack of explicit destructors – the over reliance on automatic garbage collectors and object references has given us hordes of Java developers who think the gc will automatically close database connections for them. I’m serious – I’ve almost made a career fixing that kind of junk programming. That’s how frequent that is.
  2. String concatenation (the most natural operation one could think of) producing one additional object to be garbage collected for each concatenation. It is not even funny to count the number of systems I’ve known to have their gc tanked during peak hours because of this.
  3. Vector and HashMap being synchronized, and the fact that, as of yet, they have not been marked as deprecated. This has the impact of developers erroneously using these artifacts, specially in sections of the code that experience high throughput. Why these two have not been deprecated is beyond me.
  4. Boiler-plate code and a lack of operator overloading. Anyone who thinks matrixA.add( matrixB.multiply( matrixC.scalarMultiply(i) ) ) is better than matrixA + ( matrixB * ( i * matricC ) ) is a true Java developer </sarcasm>

Thus, although Java, the language itself might be simple, there are no-so simple reasons that conjure serious difficulties for real-life, non-trivial development.

However, that is only one part of the problem.

The other problem is a cultural one. Most college graduates do not have the same exposure to the bare metals as it was the case 15-20 years ago. You could find a Java developer that has never seen a pointer in his life, nor he’s aware of memory and resource management issues that are self-evident in languages such as C or C++.

This, I believe, combined with an magical, voodoo like worship of the invisible and yet ever present garbage collection causes Java developers to be oblivious to good resource management practices.

Also, given that there is no support for operator overloading and multiple inheritance, coupled with the fact that there is nothing in Java itself that enforces interface implementations over class extension (despite the flaws of interfaces), causes many Java developers with little exposure to other OO languages to have a limited, very narrow understanding of OO principles.

Furthermore, I would not refer to "productivity" in the Java world. Instead, I would refer to "good software engineering programming practices" in the Java world. A series of technical decisions in the design of the Java language, coupled with poor OO/soft. engineering principles acquisition demonstrated by many one-language-pony Java developers cause a "good programming practices" problem that is both technical and cultural.

As it is then, with Java, simplicity and productivity are relative.

CC-by-SA

Advertisements
Tagged: ,