Java's popularity is a function of market position, the perception of one product compared to its competitors. When it first came out, Java was positioned against C++, to which it compares favorably. Yes, I miss operator overloading and a handful of other items, but these are outweighed by the fact that Java prevents entire classes of errors made by C++ developers. All of this was done before, but Sun was able to make it mainstream and practicable.
Now the Java vs. C++ battle is effectively over. Today Java's market position is measured against a variety of languages, most frequently C#, Python, and Ruby. For many of us, Java compares much less favorably to these than to C++. Proponents of these languages love to show problems solved in a handful of lines, with a Java-based solution including dozens of lines of boilerplate code. The poor Java developer is then pushed around and has his lunch money stolen.
Naturally, much of the Java community wants to do something about this. So closures and type inference have been proposed for Java 7, and the debate in the Java community begins. Some say "Hooray, Python programmers will stop making fun of me!" Others object "Don't we already have enough constructs to worry about in this language?" Throw in the glacier-like JCP, and we have no idea what the next release of Java will look like.
Can we fix Java?
I am sympathetic to both arguments. The language is getting big. If only we could get rid of artifacts like primitive types and arrays, we could remove clutter and make conceptual room for more advanced concepts. Even so, I still land firmly in the pro-closure camp. This is partially for selfish reasons; I got hooked on them while hacking in functional languages at night, and want to use them in my day job. My company uses Java because it is actually the right choice for us. No other platform offers that combination of portability, reliability, tooling, and performance. Too bad it's not with a better language.
With this in mind, the rumblings of the last few years make sense, and the future is clear. It's not about Java at all, it's about the JVM. And Sun is positioning the JVM to become a light, efficient virtual machine available everywhere. Consider everything that has happened:
- JavaFX has been announced, creating a simple, declarative model to compete with the likes of Flex.
- Sun has committed to releasing an update to Java 6 that will shrink the minimal JRE download to two megabytes.
- Sun hired Charles Nutter to make JRuby a first-class language for the JVM. The 1.0 release nears.
- Glassifish -- the open-source application server sponsored by Sun -- will run JRuby applications directly in v3, and be pluggable for new hosts. Java SE and EE need never enter the picture.
- The JVM is now available under the GPL, which should increase availability on Linux.
- The 2007 JavaOne conference included a Scala session for the first time
But what about the mean time?
The reality is Java-the-language will be around for some time to come, at least until a clear successor is established. Sun and other members of the JCP have an opportunity to define the language's legacy. As Guy Steele famously said, Java "managed to drag a lot of them [C++ programmers] about halfway to Lisp." Now Java can drag programmers one step closer to Lisp, and set the stage for the next generation of languages.
Of course, I'm referring to closures. Users of functional languages will attest how working with such constructs changes how you think. By adding closures to Java, we do more than provide a powerful tool for those of us already familiar with the construct. We introduce a large community to a better way of solving many problems. We'll see if it sticks, but I can't think of a better way to spread a thought model many believe to be superior.
Update: I actually don't think Java sucks. It meets the early goal as a straightforward replacement for C++ very well. I do believe we can create a language that is better than Java based on what we've learned over the last decade.
11 comments:
I agree with your assessment. At RailsConf Tim Bray put a pie chart up that effectively broke down into 3 pieces: 1. the JVM 2. the Java API's and 3. Java the language
Then the next slide broke the pie chart up a little differently: 1. the JVM 2. the Java API's 3. multiple languages (Ruby, Python, Java, etc...)
You are right Sun is taking notice.
Thanks
Matt
But how are they handling the drift towards FP tat you can see in .NET? Is the JVM going to support efficient tail calls? (it's interesting to note that Ruby currently doesn't, afaik, so that isn't going to help push things).
"But how are they handling the drift towards FP tat you can see in .NET?"
Scala has features of functional and object oriented languages and it compiles to Java bytecode. It is very cool, I wish I had time to learn it.
Scala language
When *did* Java have a mojo? As long as I can remember, Java has been used in boring B2B shops, typically paired with a big-iron database, stuck behind in cold&dark server rooms. :-) Since when THAT was cool? Sure there are lots of Java jobs out there, because majority of software development is exactly like this: boring "data pumping" from one table to another.
Most *exciting* new software (as always) has been developed using C/C++ or, in some cases, Python, think OSS projects on Linux, games, new compilers/interpreters, etc. Heck, everything I (and probably you) use every day was NOT written in Java.
When I think of Java, only Eclipse comes to mind as far as software is concerned. That's it: one goddamn thing.
Java never had any "mojo" to begin with! It was designed as average language for average programmers; the results speak for themself, and always have for the last 7-8 years. Considering the amount of time and money that has been wasted trying to "fix" this trainwreck, it amazes me that people only now realize the depth of the hole they dug themselves into. Sorry guys: no shovel for you!
It depends on where you're coming from. To a C++ developer who has never built a major system in another language, the fact that Java eliminates huge classes of errors can create a lot of mojo. The problem is, as I mentioned in the article, Java is no longer being compared to C++.
I really thought I left a comment on this post. Obviously somebody didn't like that...
Trying it again....
"Java is dead, Java sucks, Beyond Java, Can we Fix Java, Everything is better than Java, We need a replacement for Java...
yawn"
I don't want this blog to turn into a trolling ground, but I'll respond once. The article never says Java sucks, and in fact implies Java is better than C++. Of course, this doesn't mean we can't create a better language, or that we can't make Java better with closures or other ideas.
I also added an update indicating I actually don't think Java sucks to remove any confusion.
Great job, balanced blog entry. Just wanted to comment on the other comments ;-)
Maybe it's time you learn C++. Java never compared favorably to C++. They're totally different languages.
C++ is a language that provides low-level access but allows the building of very high-level abstractions on top of them, which could in some cases actually be considered to be domain specific languages.
For example, you can still have the same interface and efficiency as Fortran vectors just with a library, while Fortan has dedicated support for array programming in the compiler.
No other language provides that kind of functionality.
Java is just a simple high-level language focused on OOP.
What you can do with it is very little.
You're citing that Java 7 will get support for closures and type inference, but C++ always had support for those for example.
For what it's worth, I built cross-platform code in C++ for several years before transitioning to Java.
Of course, whether Java compares favorably to C++ is a matter of opinion. For me the killer feature is garbage collection, and the fact that Java eliminates many classes of errors one can make in C++.
Post a Comment