Why Java SucksA Critique of the most-hyped programming language in history
Updated: 2/17/2007 Java is probably the most-hyped programming language ever, and deserves almost none of its fame. All of it's promises can be fulfilled by existing languages or moved to standardized protocol design instead of a language. There is nothing really new that Java brings to the table. Sun is much better at marketing than at creating new languages. HP and IBM products are often technically superior or better deals, but those companies have not learned how to market the way Sun and Microsoft have. Perhaps Java's only real claim to fame is being the first language designed for web applet usage; but even that niche is being filled by Flash players and others because Java didn't do applets very well. Now it is trying to remake itself as a server language. However, it is too slow and too unpredictable (GC) for systems work and too strong-typed for application database work. Java is in for a long struggle. Just like the sinking dot-coms, Java is going to have to struggle on it's own merits (if it has any) when the hype runs out. Hype can knock you down just as fast as it bring you up. Hype is a two-edged sword.
Java's Flaws in a Nutshell
Casey Swings Foul BallI tried to include a Swing data grid in a little Java app the other day, and found the most bureaucratic claptrap thing ever seen since the Chernobyl computer. I've used grid widgets in other tools/languages, and they were far more approachable. For example, if you wanted to turn on scrollbars and change the color of the selected (current) cell, you'd do something like this:// A real kit, not Swing myGrid.scrollbars = True; myGrid.selectedColor = "#ffff00";However, Java's Swing rarely makes things this easy. You have to embed the grid in a scroll-panel widget; and to change selected color, you have to create a "column model" object, and a couple of other screwy middle-men classes. I don't want to have to care about that kind of detail; I just want to drop the food in front of the tiger, not guide the food through its intestines via an Intestine Model and an Enzyme Timing Manager on through to some Excretion Model Coordinator Manager objects, one for each glistening log. Why make me care about those!? Perhaps if you are a systems programmer designing a tool kit for mass sale or a GUI specialist for a huge project with lots of specialists, access to those kinds of details may matter. However, that's only a small portion of the programming audience and against the "easy to get going" kind of mantra that Sun wags all over the place. If it's a bureaucratic gizmo that only a mainframe administrator's mother could love, then Sun should say so. I've seen the light with real widgets, and Java's bloated API's ain't it. (Related: protocol coupling) Sun should release a more streamlined kit that hides such spaghetti. (The existing API's don't need to go away.) However, it usually takes them at least 5 years to get the kinks out, so don't expect anything usable anytime soon. (And, why the hell is the default selected cell color medium-dark purple when current-row color is medium-purple? That stands out about as well as milk in a snow storm. Did they hire Stevie Wonder to design the color scheme?) Event ManglersAnother annoyance is how GUI events are handled in Java. Good GUI kits use "on-X" methods to be defined for each widget object. For example, a button object would have an "onClick()" method. To add activity to a widget, you simply fill in the related on-X event's method. That's too simple for Sun I guess. Whenever the simple route presented itself, Sun avoided it. The developers were paid by the number of classes they could invent, it seems, coming up with the round-about "listener" doodads to add to their class count.
Java Proponents Can Be Very WrongAn article on the JavaWorld website about Java and GUI design by Allen Holub made some strong claims about procedural/relational programming that are misleading or wrong.
Changes come in many different forms. Optimizing a grouping for one type of change often disadvantages a different kind of change. OO often emphasizes "noun-oriented" changes at the expense of "verb-oriented" changes. It is no free lunch and verb-orientation is just as important an aspect as noun-centricity in my opinion. See Shapes Example and Aspects for more on this.
While I personally agree with the first part of this sentence, the second remains largely unproven.
An object-oriented solution tries to encapsulate those
things that are likely to change in such a way that a
change to one part of the program won't impact the
rest of the program at all. For example, an object-oriented
solution to the problems I just discussed requires a Name class,
objects of which know how to both display and initialize
themselves. You would display the name by saying "display
yourself over there," passing in a Graphics object, or
perhaps a Container to which the name could drop in a
JPanel that displayed the name. You would create a UI
for a name by telling an empty Name object to "initialize
yourself using this piece of this window." The Name object
might choose to create a TextField for this purpose, but
that's its business. You, as a programmer, simply don't
care how the name goes about initializing itself, as
long as it is initialized. (The implementation might
not create a UI at all -- it might get the initial
value by getting the required information from a database
or from across a network.)"
However, trying to engineer for every pre-conceived change into a system before the requirements even happen is often not wise. For one, to prepare for all of the potential options, such a component may require a large interface. As programmers come and go (or forget), they will have to slosh through this interface to know what is relevant and what to ignore for the moment.
This is frankly a bad idea! What if you don't want ID to appear on every screen? For example, on some screens there might not be enough room without manual re-arrangment of fields (automated esthetic adjustment is not something computers currently do very well). Or, perhaps some viewers are not to have access to see Employee ID. For example, external (B-to-B or B-to-C) clients may be limited to just seeing a name. The author is risking the exposure of internal information to the outside world. Such blunt propagation of changes could be done just as easily with a procedural approach (assuming a well-designed GUI protocol), but I won't risk endorsing the idea by describing how. He Does It AgainThe author evens brags about similar techniques in an article titled The Incredible Transmogrifying Widget. An excerpt:"...looking at a widget that I use all the time: a wrapper around a Collection capable of creating a visual proxy that automatically changes its appearance. By examining the amount of screen real estate available to it, the widget displays the Collection as a combo box, a list, or a button that pops up a frame containing the list when pressed. This sort of dynamic adaptability is essential when implementing user interfaces for object-oriented systems, since the context in which a particular attribute will be displayed is often unknown at compile time." [Emphasis added]Imagine how a user would feel if one time they come to a screen to be faced with a pull-down list, and then later a button that says "see list...." after selecting a few different options or shuffling screens around a bit. Consistency is an important trait in user interface design. Lack of consistency tends to confuse and/or distract the user. The user may pause to think, "Hmmm, why did that pull-down list change into a button? Am I in the right screen?" One should not make the screen keep morphing around unless it is the only practical option left. I would have to look at a specific case to weigh and present the tradeoffs involved. However, morphing widgets and layouts should be a last resort only.
More Java BS-Busting to come . . .
Main | OOP Criticism | OO-BS in Media |