Summary
Publicly-held corporations ostensibly serve the people they sell products to, but are required by law to actually serve their shareholders. Privately-held companies only serve the customer.

The problem with public corporations is that, no matter what they say, "maximize quarterly profits" is the real mantra.

Apple and Sun are both notable exceptions. Apple is run by a charismatic leader, a benevolent dictator who is able to reshape the company in his image. Which is great, as long as he is around (as they discovered when he wasn't).

Unfortunately, no one has been able to figure out Sun's business plan. When McNealy was at the helm, the business plan seemed to be "Microsoft is bad." This went by the wayside when Microsoft paid them a billion dollars (seems like it would have been cheaper for Microsoft to just buy a billion dollars worth of stock and save the legal fees) in the Java legal settlement. Hmm ... I guess this makes Java the most profitable thing Sun has done for the last ten years.

But Java was created in a company run by a hyper-competitive CEO and the whole culture around it has been competitive. Many decisions were made without the consumer (programmers) in mind, but with Sun's apparent best interests in mind. For example, generics and closures and a number of other features could have been added -- cleanly -- in the original language, but there was a certainty that it had to be rushed to market or an important opportunity would have been lost.

Java's philosophy has always been a "directing" one -- "we know best and will tell you what to do." When not overdone, this can be helpful, and is part of the abstraction process. "Don't worry about the stack frame, we'll take care of that for you" is something that no one argues about, for example. But it's very easy for this attitude to go too far, especially when coming from a corporate entity that consciously or unconsciously modeled itself after Microsoft (who is now busy telling its customers that they can't use Windows XP even if everyone now knows that Vista is inferior). Obvious decisions include the invention of checked exceptions (not repeated in any language I know of). Or the decision that backward compatibility was more important than usability in generics. And I've lost any hope that the eventual design for closures won't be the most bolluxed one, because Sun has a long history of choosing the design that serves the wrong needs (Think AWT. Think EJB prior to version 3. We should make a list).

A very important impact of these decisions has been in connecting to the OS. Early on, the "write once, run everywhere" chant started and that justified everything. If you want to talk to something OS-specific, you can use JNI, right? What a nightmare. And the joke became "write once, test everywhere."

And then there is the "transcendental functions" decision, still staunchly defended, in which some of the floating point processors didn't follow the IEEE floating point standard out to the far right of the decimal point. The solution was that all transcendental functions in Java are done in software, and as a result painfully slow. This decision should have been stamped on the box: "warning: if you get sucked into using this for numerical apps, you can easily get screwed," but instead the language was promoted as a solution for everything -- because that's the corporate way of doing things.

Sun, as is its habit, never learns from its mistakes. Sometime in the last couple of years, rumor has it that Adobe apparently extended the possibility of working with Sun so that Flex would integrate seamlessly with Java. This would seem like a best-of-all-worlds situation, to pal up with the folks who have been specializing in UI programming. Instead, that seems to be around the time that JavaFX was started (which even poached Flex's "Fx"). The classic "not invented here" response is the standard reply of corporate competitive-think.

Open-sourcing Java is not going to make it an open-source project. The culture that has built up around Java for over ten years is not going to change just by moving to a new license.

A truly open-source programming language does not have shareholders to serve. It can only serve its actual customers, the programmers who are consuming the language. For example, Python has always been about "what do you want to do today?" If you want to create a cross-platform app, no problem. And if you want to talk directly to the OS, that's been made as easy as possible. This makes sense because Python is an "enabling" language -- it's about helping you do what you need to do, rather than telling you what you can and can't do (these comments also apply to Ruby and other enabling languages, but I only occasionally tinker with Ruby so I can't speak authoritatively about it).

Python, after thrashing around with many different approaches, also solved the "interfacing to native code" problem. In Python 2.5, ctypes were added. Now you only have to say "there's the DLL, connect to it as efficiently as possible" and it does it. And amazingly, the DLLs are the only things that are different on different platforms; your Python code can be the same. That's the right solution to the problem. (When Jython 2.5 comes out, I've heard it will have ctypes working so that may be the reasonable alternative to JNI).

There are numerous examples of code that take minutes in Python and require hours or days or weeks in Java. The response from the Sun Java camp (obviously not the camps within Sun that fund JRuby and Jython!) is that this is the Java way. Rather than fixing the problem, respond with rhetoric (another lesson learned from Microsoft).

Will Java become much better once it is open sourced? That should be no problem, once 10+ years of culture is reversed. I heard a podcast where someone in the JCP was arguing that "people should stop complaining about the process and instead join it, and after a few years things would change." In a few years a lot of other things will change, and the internet is only accelerating this change. No one has time to wait for an ingrown culture to catch up; instead they will move on to other things.

Java won't die. But the adoption of new Java versions and features is going to continue to slow. People have been bitten too many times. Java lost its status of being a leader awhile ago, and it's now a legacy language -- it's just taking awhile for everyone to realize it.

As I've argued before, legacy languages aren't a bad thing. Having a language that is not constantly thrashing about is good, in fact. You can focus on solving your problem rather than stressing about whatever new abomination Sun is going to visit on the language (yes, yes, I know it's all the JCP. I'm sure lots of people believe that).

The JVM will be the most important legacy that Java contributes to the computing world. With years of optimizations and a platform with built-in garbage collection and exception handling, it provides a foundation for rapid development of new languages like Scala and Groovy (which play well with Java right out of the box), as well as ports like JRuby and Jython. The JVM was certainly one of the primary inspirations for .NET (and if you don't think there are important things going on in that arena, look at LINQ).

Java itself will continue to be a core workhorse, just as C++ has been. But like C++, I think people will reduce the use of the more difficult and newer features and keep their code simple, mostly because they will only be doing small portions of applications using those languages and will do whatever they can in the more powerful enabling languages.

Clarification: So there's no confusion, I am for open-sourcing Java. It's an important step. I am just skeptical that open-sourcing will have any magical positive overnight effect on the culture and infrastructure that's built up around the language.

Full disclosure: My consulting contract (mostly speaking, some free-form writing) with Adobe expired around last May (and yes, Adobe is a full-on corporation with all of the problems that implies -- but according to rumor it was Adobe that suggested the liaison with Sun); I decided on my own that Flex is a good solution for UIs, both before and after that contract. Also, James Ward and I just published our coauthored book (written under our own steam, not part of the Adobe contract) First Steps in Flex. I'm working on an open-source book on Python 3. And before you say I've gone totally anti-Java, I also organize The Java Posse Roundup with The Java Posse (so think "tough love").

Talk Back!

Have an opinion? Readers have already posted 19 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Bruce Eckel adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Bruce Eckel (www.BruceEckel.com) provides development assistance in Python with user interfaces in Flex. He is the author of Thinking in Java (Prentice-Hall, 1998, 2nd Edition, 2000, 3rd Edition, 2003, 4th Edition, 2005), the Hands-On Java Seminar CD ROM (available on the Web site), Thinking in C++ (PH 1995; 2nd edition 2000, Volume 2 with Chuck Allison, 2003), C++ Inside & Out (Osborne/McGraw-Hill 1993), among others. He's given hundreds of presentations throughout the world, published over 150 articles in numerous magazines, was a founding member of the ANSI/ISO C++ committee and speaks regularly at conferences.