Nathan CrauseMusings of a Software Developer

One of my biggest pet peeves is when self-proclaimed geniuses (I'm looking at you Guido van Rossum and Yukihiro Matsumoto) bash Java for what they perceive as shortcomings (whilst boasting about how wonderful their own languages are). As if that wasn't bad enough, this invariably leads to claims of the demise of the Java programming language.

First off, let me just say that statistically, Java is far from dead. Not even close, folks. Here are just a few links which clearly show the languages ongoing popularity:

• LangPop.com
• TIOBE Software
• Ohloh (I've just hand-chosen a few languages)
• Indeed.com (tracks job trends - hand-chosen languages)
• Google Trends (used the language name + "jobs" as the search terms)

Okay, so it's blatantly clear that the language is alive and well. Now on to the criticisms of the language itself:

1. Not everything is an object (primitive types): one word - speed. If you had to encapsulate absolutely every single mathematic equation's atoms into objects, the result would be so insanely slow (see Ruby for a clear example of this performance hit).
2. Swing is ugly: which part of it exactly? It's a pluggable UI allowing you to create native bindings (Apple made a Cocoa binding, Sun has a GNOME binding for Linux and OpenSolaris). These native bindings even increase the speed of it. If it's ugly, just change the look-and-feel!
3. The syntax is ugly: that's a matter of personal preference. I personally cannot stomach the Python syntax. To me, the Python syntax mutually excludes it from several areas of functionality, as it would make the usage utterly ugly. Here's a real example: I once tried to use Python as a scripting engine in the browser. However, because it's syntax is so incredibly rigid (with no added benefit of the rigidity), embedding the scripts inside a page resulted in some truly hideous looking HTML. The same is true for certain common syntax usages of Ruby - seeing "x<<(my_hash||{})[:my_array]||[]" is extremely ugly.
4. It's slow: this is so a 90's argument, and anyone who still makes it obviously hasn't run Java since that time. So many tweaks have been made to the JVM that on Linux (as an example) when doing certain tasks, it actually outperforms even native C. Granted, it's String functionality is a little slower, but this is really because all Strings are natively UTF-8 encoded in Java, which is a good thing (try supporting multiple languages in PHP or Ruby sometime, and see how much fun that is).
5. Applets are slower than Flash: They are slower in loading, there's no argument there, but they are in no way actually slower once both are running. Visit Wowhead sometime, and view a model in 3D using Flash and Java. Java takes about 3 times as long to actually load, but once it's up and running, the 3D rendering is an order of magnitude faster and smoother than Flash. Rendering speed aside, Java also provides vastly more functionality than Flash. Given sufficient permissions (as an example), an Applet has access to the full range of the Java API, including direct SQL database access, Remote Method Invocation, rendering outside the browser window, etc., etc. While some of these things are certainly possible under Flash, they always involve peculiar work-arounds (such as an HTTP script acting as a node to the SQL database). One of my personal annoyances with Flash is the inability to use the right mouse button in the application (it is reserved for Flash's own internal context menu). On top of all of that, on my personal projects there is also the issue of raw mathematic power. I personally cannot see Flash being able to directly support 2048-bit asynchronous encryption from within an application (excluding built-in support for SSL/TLS); nor even have the capacity to generate a primary number that large.
6. Java requires more lines of code: This is traditionally an argument raised by Ruby and Python programmers. No disrespect to those languages, but my personal experience clearly shows that while Ruby may require fewer lines of code initially, as a project progresses this is no longer the case. This is because the Ruby language itself provides no way of controlling the type of data being passed around. So, you may write a library which takes in a parameter, and so long as anyone using that library only ever happens to provide that type of data all is well. And then someone passes in something unexpected. The **** literally hits the fan. You then have to go back, and start adding in all sorts of "duck-type" checks to make sure the data passed was the type expected, etc., etc. Suddenly, your code has expanded a rather copious amount. This also holds true for exception handling. Since Java expects you to catch (or adds "throws" clauses to your method), as a programmer you are immediately aware of potential problem areas, and can handle them on-the-spot. By contrast, Ruby will arbitrary throw out exceptions unexpectedly and only under very certain conditions, which might be impossible to predict. This creates a very real level of instability. Entropy may be great for encryption, but it should have no place in your code.
7. The JRE is too big: You asked for it. Sun only adds APIs and libraries when there is pressure to include them. People complained that there was not enough functionality built right in, so Sun obliged, and now you all complain about that, too. Make up your minds.
8. No support for enclosures: Neither does C, C++ nor even JavaScript (which uses anonymous functions instead), and nobody complains about that. Sun has done what I found to be a fairly good work-around in the form of anonymous classes, and it certainly does the job (see the BDD framework in the JavaStubs project which makes heavy use of this). By using interfaces which you implement as an anonymous class, you additionally create predictability, because you emphatically know before-hand what data is passed into your code block, instead of guessing like you do with Ruby enclosures.
9. Database access it too difficult: Which one? Is this a reference to raw JDBC connectivity? What about iBATIS? Hibernate? Spring? There are so many good choices that it renders such a vague argument as complete ignorance.
10. It's too difficult to learn: You're lazy, and must be a VisualBASIC programmer. You do realise your language stands for "BEGINNER'S All-Purpose Symbolic Instruction Code", right? Stop being such a whiney Beginner, and learn something better (even if it isn't Java).
11. Java Enterprise is ugly: Considering that Java Enterprise gives you such freedom to choose what you want to use, I don't understand this argument at all. Don't like EJB's? Nothing is forcing you to use them. Don't like container managed persistence? Then use bean managed persistence. Java Enterprise is all about freedom of choice. How many database management choices do you have with Ruby on Rails? Let's see ... ActiveRecord, ActiveRecord or ... you guessed it ... ActiveRecord. How is this freedom of choice?
12. Java Midlets are dead: You're trapped in a Reality Distortion Field - stop believing every bit of drivel that spews forth from the chasm that is Steve Jobs' mouth. The iPhone's lack of MIDP support is a money-making mechanism, nothing more. If the iPhone had a Java runtime, then Mr. Jobs would have no way to bill you for every little bit of software, and he would have no governance over what you are allowed to install. That's right - Steve Jobs has total control over the content you're permitted to have on your precious little toy. Mr/ Jobs' argument that Java is a "too heavy" for the iPhone is a blatant lie. the iPhone uses a Java-enabled CPU which executes Java bytecode natively. Hardly a "ball and chain".
13. Java is a dinosaur: I actually got this comment from an Objective-C programmer. I never got elaboration as to what he meant by this, but there's a finite number of interpretations.
    1. It's old: coming from an Objective-C programmer, this is a laughable argument. Objective-C appeared in 1986, Java in 1995. Argument is a failure.
    2. It's big: some would argue it's feature-rich. Of course, if you intend to use Objective-C on any platform other than MacOS X (such as under Linux), you need to install a monster-load of packages (virtually an entire new desktop with API's) just to get a single line of Objective-C code to compile. Argument is a failure.
    3. It's a lizard: ummm ... okay?
14. Java has poor documentation: I honestly fell off my chair when I got this from a Ruby programmer. Any sane person comparing RubyDocs to JavaDocs cannot come to this conclusion. Sun's JavaDocs are verbose and complete with full examples. I actually learned how to use regular expressions from Sun's JavaDoc on the java.lang.regex package. Most of Ruby's "documentation" is the source code itself. I understand the idea of code being so sweet and juicy that it explains itself, but when a given process is several layers deep across multiple modules and classes, then this entire idea crumbles. Instead of having a single spot where you can see a methods usage and possible results, you have to walk through your source code, trying to piece together what it does. This goes hand-in-hand with the exception argument from point #6 - you have absolutely no way of knowing what possible error conditions may occur until you've stepped through the entire source tree of every single bloody method. Complete insanity. Also - any English teacher will tell you that when you are describing a word, you cannot use the word itself in it's own definition (i.e. "What is a pen?", "A pen is a pen that you write with"). Hence "code describing itself" it a total fallacy.
15. Java isn't easily understood by the average person: as compared to what? I've tried both Python and Ruby, both which profess to be usable by the average person. Sure, the wording was warm and fluffy, but making the program actually do anything wasn't any easier at all. If a non-programmer cannot think in a logical way to problem-solve, then no amount of warm and fluffy wording is going to solve that problem. Combine this with #14 where the documentation is the code itself (which then assumes that the user even understands the code to begin with - not something "the average person" would know) you end up with a completely failed argument.
16. C#/.NET is the future: good to see the Microsoft Disinformation Machine is working at full capacity, even with the departure of Silly Billy. Here's the thing - C# (and .NET in general) was branded as the big replacement for Java - it would be cross-platform and cross-language. However, Microsoft has no interest in any platform other than Windows, and this can be clearly seen in .NET. I've tried many times to run .NET applications on Linux using Mono (an officially licensed .NET runtime), and maybe 25% of the programs actually worked. The .exe files created (a very Windows thing) were so Windows dependent that the fact that the program was written in .NET was completely irrelevant. So this means if you're interested in cross-platform development, you simply cannot assume .NET will work for you - you actually have to specifically cater for the individual runtimes. Visually, a .NET GUI application which was compiled on Windows looks absolutely terrible on Mono - which means you have to engineer your UI for each individual platform. Now - let's look at some additional numbers. Java was released in 1995, C# was released in 2001. Using Ohloh's language comparison tool, we can see Java hovers at around the 15% mark. C# is consistently below 5%. Over 8 years, C# has made absolutely no significant impact on the language scene. Even Python's statistics are double that of C# (it's interesting to note that Python appeared 4 years earlier than Java, yet Java leapt past it - take that Guido van Rossum).
17. Java doesn't have mixins: thank GOD it doesn't!!! On outward appearances, mixins seem like a really great idea, and allows you to define some nice arbitrary bit of functionality which can be used all over the place. In practice, it makes debugging virtually impossible. Besides, isn't that sort of thing bad design? If you have a certain process which needs to execute but doesn't really belong in a superclass, isn't that a fairly clear indication that you need to create a new class specific to that sort of functionality? No, I see no benefit whatsoever to mixins, and I see no problem with Java never supporting it - it really has no need to.
18. Anything you can do in a Java Applet you can do in Web 2.0: I'd certainly like to see that, actually (see my "Throwing Down the Gauntlet" post). This is similar to point #5, so I won't go into too much detail here suffice to say that Web 2.0 cannot provide the same level of mathematic computation power, cannot provide local file-system access, cannot thread, etc., etc.

Well, that's it for now. I'll come back and post more on this when I have time.