Joshua Marinacci's Blog

JSR Archives

Java's got a Bad Rep: The Rebuttal

So it's been a week and I've seen a lot of response to my last entry. One commentor in particular asked for a point by point rebuttal; which struck me as a spectacularly good idea. Here are the bulk of the arguments and my responses.

The Arguments

• Java isn't Free / Open Source / GPL / RMS-friendly
• Why use Java when there are plenty of native languages / environments to choose from.
• Java is missing templates / preprocessors / lambda functions / other advanced language feature that only backwards cave-dwelling languages lack.
• There aren't any applications written in Java. It must be a failure.
• Java / Swing is slow, looks bad, and doesn't feel native, doesn't let me do cool stuff like animation, 3D, or sound.

Here we go.

The Rebuttal

(1) Since it's such a huge (and apparently controversial) topic, I am covering the open sourcing issue separately in this other post. However, in summary, opensourcing doesn't solve our problems and buys us very little, in exchange for a lot of new problems. Follow the link for a full analysis.

(2) Why use Java when there are plenty of native toolsets to choose from? Well, first of all, it's better than a lot of them. If you want to write an application (not a script or a device driver) then Java provides you with a good toolset, great libraries, and a clean language which learned from the mistakes of the past. It's simply a good applications language that can make your programmers more productive.

Java can also be "write once, run anywhere". For people who need to support multiple platforms, especially more esoteric ones where you could never hire a native expert (say the palm pilot, or win 98), or if you simply don't want the headache of dealing with bizarre version issues, then Java provides you with a consistent platform to code against. It's compile once, run anywhere features are especially important in the age of ubiquitous networks with code flying over the wire. Java Webstart has been a godsend to companies with locked down desktops spread over the globe. (potentially running eight different versions and patch levels of Windows).

So why use Java? Because its better than a lot of the alternatives for writing applications.

(3) Java is missing language features. This is probably more a matter of taste than anything else, but Java isn't lacking features because no one thought to add them. Nothing in Java is new. Every part of the system, from language to library to VM, was carefully considered against the 20 year history of OO languages. Preprocessors were left out for a reason. So were pointers. Java is missing a lot of the more esoteric features, but most of those features aren't used in day to day programming anyway. A few of them, like generics, are slowly becoming more mainstream, and Sun is adding them as people ask for it. Remember, computer languages evolve slower than hardware or software platforms. It took 20 years for inheritance and polymorphism to become common place (and it's till not as common as you might think). The features Java is supposedly lacking we really shouldn't miss. And if there's something you just have to have, then you can use one of many addons to provide it like XDoclet and Shark, safe in the knowledge that if it compiles to Java bytecode then everyone can use it.

(4) Nobody uses Java. This simply isn't true. Probably 99% of Java applications are either serverside (where the user doesn't know or care what the application is written in) or are made for internal corporate use. As Eric Raymond pointed out: "there is empirical evidence that approximately 95% of code is still written in-house". Most Java applications, even Swing apps, are for corporate use. In these environments the robustness, productivity, and easy of deployment more than make up for Java's other flaws. There are plenty of high quality applications that people don't know are written in Java, and that's really the problem. Especially on the desktop I'd like to see more highlighting of Java success stories (and more ways to get the word out!)

(5) Java is slow, ugly, and doesn't do modern native things. I've saved this for last because I think it's the biggest problem. Java has this impression because, well, it was slow and ugly. Back when Java debuted nothing worked properly, applets were slow to load, and AWT used a horrid subset of the available widget set on each platform, all of which looked different and ugly.

Today the situation has changed. Swing has gone through several revisions to become a powerful toolkit, if complex. The speed issues have mostly gone away from improving the libraries and a decade of faster processors. Even on my now aging iBook I run jEdit quite nicely and have written tens of thousands of lines of code with it.

Swing itself has also matured (and gotten prettier). Most of the big bugs have been fixed. Quite a few attractive Look and Feels are available from Sun and 3rd parties. A lot of the missing functionality from the early days is finall in place. It is entirely possible to make great desktop applications, even consumer apps, with Java. We just need to get people to realize it.

The plan

Despite all of my argument preceding, Java still has an image problem. People still think that you can't write good desktop applications in Java because they don't see them. So what can we do? Show them! And keep building more!

First, we need to show off the good apps. Get the word out. I think we need a place to highlight great applications. Perhaps a sidebar on Java.net with a new application each day. The only requirement is that it be a desktop application with a downloadable demo. This spot should have it's own RSS feed and archive. Then we have to start the publicity. Get other sites to link. Make a download.com for Java apps.

Second, create a place to collect all of the tips and tricks it takes to make a quality desktop application. I've started a Wiki node here with a framework of what we should pull together: exe packaging, good look and feels, swing tutorials and articles, how to work with different kinds of media. Contribute whatever you know. We need to fill out the missing pieces.

Third, start a contest for quality Swing applications along the lines of O'Reilly's MacOSX app contest. We should have different categories for commercial and open source, full applications and mini programs, and maybe further sub-classification (word processing, media and graphics, personal organization). We'll probably need to get a corporate sponsor for this.

We all know that Java can make great software on the server. It's time to reclaim the desktop. (Wiki Here)

An Analysis of Open Sourcing Java

I'm going to try to really tackle the issue of opensourcing Java and state my opinion of why it's a bad idea. Then I'll propose a way would could do it without all of the problems. It's a long one but please read to the end and provide your feedback. This is an issue that many feel strongly about and has the potential to influence Java's long term future. And as a career Java developer, it's something that personally concerns me.

Note, I don't want this to become a Microsoft slam. I think they have made many fine products over the years in addition to some really bad ones and some very questionable business practices. I do have to respect them for the fact that they never give up. They keep working on a good idea, even if it takes five revisions before their product is succesful. In this post I am only discussing Microsoft's actions in relation to Java. Who knows, had I been in the shoes of a VP trying to grow the desktop market (which is hard with 95% penetration) I might have done similar things.

I'd also like to mention that here I use Java and JVM interchangably. I am more than familiar with the difference between the language, the VM, and the libs that make up the runtime (and dear god, please don't make me explain again the difference between Java and JavaScript. :); but for the purposes of this discussion I will consider them all part of what makes up Java. I think this makes sense for the kind of highlevel issues we are talking about.

The Debate: Open Sourcing Java

A lot of people have been talking about the war of words between Sun, IBM, and related parties on the issue of open sourcing Java. Even James Gosling and the Slashdot crew have gotten in on the act. But what would open sourcing Java actually do? What kind of benefits would we, as a community, get?

As a Java developer, and I'm assuming that most of my audience for this post is a Java developer, I really don't care about the politics of a license. RMS may opine that without a free Java you can't implement a completely free desktop, but I really don't care about an abstract sense of free. I care about what an open source Java would actually mean, and how it would actually affect me. To me it breaks down like this.

The Benefits of Open Source Java:

• Multiple eyeballs fix all bugs
• The ability to fork Java if you want to add new features or fix bugs
• The ability to take Java (non-forked) in new directions that Sun wouldn't think of
• Keeping Java alive if Sun tanks
• The ability to make sure no one else can 'take Java away from us', ala Microsoft's embrace and extend policy

The Problems with Open Source Java:

• Multiple incompatible Javas (both language and environment)
• People from one team not listening to other teams. Standards wars.
• Someone else co-opting the entire system to make it proprietary without a large company to defend it.
• A monoculture of VMs (which is not incompatible with the idea of multiple VMs)

Now, as a developer, I don't care about competing with the Jones' (.NET, perl, C) or about the politics of freeness (RMS). I care about making and deploying great applications, and deploying them everywhere. For this reason I love the advantages of open sourcing Java. It makes Java better and lets me play with it. Still, I really hate the disadvantages. #1 on the list is multiple incompatible environments. The current JVM situation, with multiple revisions and platform specific bugs, is bad enough. Imagine if there were 10 or 20 JVMs out there each with their own idea of what "Java" is. Chaos for the developer. I think this is the number one reason that J2ME has failed. There are too many propriatary extensions and platform incompatibilities to make it easy (or even feasible) to develop J2ME software. I'd hate to see that happen on the desktop or server. That makes my life as a Java developer, (and let's face it, we are the only ones who really care this passionately about a programming language), simply hell. In the end we would still need a validation to ensure that all widely deployed Java environments are compatible, and we'd basically be where we are now, with Sun's compatibility tests and control over the spec, only with more fighting and less work getting done.

So what else do we have here. Multiple eyeballs fix all bugs. Well, you can already download the source and fix a bug if you want to. You can even submit the fix to Sun. You just can't get the fix to your users (or the rest of the world) in a timely manner. This is a problem but one that doesn't require GPL'ing Java. In a world with Open Source Java we could still have these problems. The only solution is an active developer team with an interest in accepting feedback. (more on this down below).

Next up, the ability to add custom features. People have been doing that for years with custom JVMs and compiler extensions. GPLing won't change that. Taking Java in new directions already happens with the JCP. The process may have some problems with infighting and general slowness to decide anything, but open sourcing would mean we'd have even more people bickering about trivial issues. (And if you think that's bad, trying sitting in on a city council meeting sometime.) This would make the problem worse, not better.

Next is the issue of Sun going out of business. I think that Java would be fine without Sun. It's a language, carefully spec'd out, with multiple implementations from many organizations, some with billions of dollars. (Hint. It's a TLA). If Sun went out of business tomorrow we'd be fine. I can't say the same about MFC and Win32.

One really odd issue is the monoculture problem. We could have all JVMs derived from a common source (and why not since it's freely available, and in fact the GPL encourages a single source), so one flaw would affect them all. This is the danger of a monoculture. This is a problem even if we have multiple JVMs with incompatibilites. Having multiple implementations of a single spec helps prevent this. I like the idea that a bug in the Windows VM doesn't necessarily affect the OSX one, just as I like being immune to Outlook viruses by using a different IMAP compatible email client.

Finally, open sourcing, particularly with the GPL, would protect Java from an embrace and extend attack from a hostile company, which pretty much means Microsoft. I don't think that it would since they have already done it twice. The GPL wouldn't have stopped what they did. First was an incompatible JVM. Lawsuits happen, years pass, MS settles, and the damage is already done. The GPL wouldn't change this. Second, MS takes the good ideas of Java and makes their own in the form of C#, adding lots of cool new research. Again, the GPL wouldn't stop that. No license (or contract, or law), will stop a determined foe. Only humans with their own interests can stop other humans. Any license can be powergamed around.

So now we can see that opensourcing Java doesn't solve anything. We have problems, and I'd like to see some changes in the way that Sun handles things, but by and large they do a good job and just GPLing it all would introduce great headaches for very little gain. I urge anyone who thinks otherwise to submit an opposing analysis. This really is an important issue and I'd like to have some frank realworld discussions about it.

As a final note (and I'll stop bugging you, I promise) remember that open source excels at building software where the solution is already known (like most of the Unix utilities we take for granted. No one wants to reimplement grep) or where the advantages of customization out weigh the costs of usability, installation, or integration (like Apache). I think this may apply to some parts of Java but not to others.

So I have one suggestion: I would like to see Sun partially open source parts of Java. Development of new standards and specs are pretty well taken care of by the JCP, but I'd like to see them open up the implementation to Swing (my personal interest). I want them to basically put the whole thing into CVS and start taking patches. Make a few Sun employees the architects and lead product managers. They still make the final decision about what makes it into an official release (JRE 1.6, 1.7, etc), and non official releases can't be sold or distributed as Java, but we'd still the the advantages of faster turnaround, multiple eyeballs, and customized versions for certain situations. This would sort of be like what happens with the Win LAF, (a project created to fix the problems with Swing's built in Windows look and feel), but more official and with the ability to move Swing along faster. There's a large community of people who want to make Swing better (and soon).

This work is licensed under a Creative Commons License.