This series argues that there’s an opportunity for some technology to become “The Java of concurrent programming”. For background then, I’ll try to capture the factors that led to Java’s success as the first mainstream object-oriented platform for application developers.
[This is part of the Concur.next series. I’d like to use this series as a sort of hub, so if you publish a substantial piece on the Java part of the concurrency metaphor, shoot me a link.]
Good Engineering · Java is good. I know that in AD2009 it’s fashionable to sneer at its verbosity and boilerplate and generics and things like TransactionAwarePersistenceManagerFactoryProxy. But if what you want is a statically-typed curly-braced highly-portable object-oriented programming platform, Java is a good one.
Free · I don’t think this gets enough credit. No computer programmer was ever asked for money in exchange for the use of Java. This was probably Java’s biggest competitive advantage against Smalltalk, which for many years you had to pay for if you wanted a decent version.
Libraries · Java came out of the gate with a pretty-big and not-too-bad set of libraries that hit an 80/20 point in meeting basic programmer needs. This was an immense relief to anyone stuck in C++ STL hell.
Familiar ·
Java came with { and } and ++
and ;. So the code, on first glance, was legible to the
legions of C and C++ programmers, who, if they had any grasp at all of
object-oriented thinking, could become competent Java developers in short
order.
BigCo Backing · The fact that Sun was behind Java mattered. In the early/mid Nineties, Sun shipped those glamorous workstations and nifty RISC processors and Unix and NFS and was totally down with the Net; geek mojo out the ears, and also commercial respectability.
Which of These Was Most Important? · Missing any of pretty-good, library-equipped, and free probably would have been fatal. Being familiar was helpful. I used to think that BigCo-backing was a big deal, but Perl, PHP, Python and Ruby have all become mainstream working from the grassroots up. But I still think it would help.
Back to Concurrency · As I survey the landscape, I’m just not going to invest time in looking at things that are badly-engineered, or missing essential libraries, or you have to pay to use. I think big-vendor backing could matter a lot.
Familiarity? It’s not a binary thing. Scala is a reasonably comfy place for a Java-head; Haskell and Erlang are each profoundly weird, relatively. Is that a fatal flaw? And Haskell feels way stranger than Erlang. Does that matter?
Contributions
Comment feed for ongoing:
From: Duane Nickull (Oct 01 2009, at 13:17)
Tim:
I also think that Java benefited from a strong community. The community aspect is often overlooked WRT many languages and technology offerings. A healthy community fosters resources like code samples, peer to peer mentoring, conferences (JavaOne, jFall etc). This is essential for drawing in new developers into the ecosystem. Compare the SAP ABAP vs. Sun Java communities - who would you rather have beers with? Sun did a great job here for Java. Will be greatly missed.
[link]
From: MenTaLguY (Oct 01 2009, at 13:18)
On the concurrency front, one thing that the JVM really, really needs badly is support for coroutines.
The general pattern for concurrency libraries these days is to employ (native) threads as virtual CPUs, and use a more or less task-specific scheduler to distribute work items to them.
(Interestingly, asynchronous I/O libraries are also converging on a similar pattern.)
Absent runtime support for coroutines (or at least generators), the best you can do when programming in such an environment is some variation on explicit continuation-passing (Scala's "react" is probably the most natural variation on this).
[link]
From: Seth Ladd (Oct 01 2009, at 13:28)
I love watching the pendulum swing back and forth. History is full of oscillations. The danger is either thinking that this hasn't been done before (and thus not learning from the past) or not realizing that the hot new toy of today will eventually fade away.
I think there is a lot to learn from Java, as Tim points out here. It's a great environment, if not a really good language. The next big language should learn that to succeed, an environment needs to built and supported (big money, lots of libraries, community).
If I had to predict, I think there will be a backlash against Ruby as people grow to realize how dangerous it is and how many tools and processes we need to put in place to compensate. (disclaimer: I love Ruby) But as I stated above, the pendulum swings eventually.
We moved from Java to Ruby, because we were tired of the { and } and the static typing and the compilations. But I predict we'll move to Scala next, because people will realize that compilation, if done quickly and without being caught in JAR hell, actually is a great set of Unit Tests.
Not to mention that Scala is the evolutionary step that seems to build upon the past while introducing many enhancements.
It seems like Scala is just missing the marketing.
[link]
From: Glenn Vanderburg (Oct 01 2009, at 15:22)
I can think of two other things that helped Java succeed, both of which don't seem like big deals now, but they were huge in 1995.
First: it came with the source code to nearly all those libraries you mentioned. That made up for all kinds of inadequacies in documentation, and helped programmers to learn how things worked under the covers.
Second: dynamic loading with a binary distribution format that was both platform-independent and easy to explore. If you got hold of a 3rd-party library (including one that was part of a product) you could still easily inspect it (with the javap command), learn about the classes and methods, and poke around until you figured out how it worked, even without source code or documentation. That made it possible to hack and extend systems even if no extension interface was documented. In other words: systems built with Java could be made to do things the authors never intended. In the late '90s, Java developers did that a *lot*.
Again, none of this seems that revolutionary now, but that's at least partly because Java taught everyone how important those characteristics are.
[link]
From: Jan Mikkelsen (Oct 01 2009, at 18:17)
BigCo backing helped a lot and shouldn't be underestimated, but I think the biggest thing was JDBC and the database vendors supporting JDBC (a side effect of BigCo support.)
What that meant was that Java became a very low-friction way to connect to a database. You had ODBC on Windows, which had its own set of pain but it was reasonably predictable. On non-Windows platforms you were in for a bunch of vendor specific pain and then you had all kinds of ways of writing your code. Embedded SQL with DB2 and binding packages was very different to Oracle and OCI, which was different to Informix's approaches, which was different to ...
With JDBC, you got the jar, set up the connect string and off you went.
In my view, that was the biggest thing that helped Java get going.
[link]
From: Peter Speck (Oct 01 2009, at 18:48)
It had GC and was the first wide-spread language to use hierarchical name scopes (packages). This made using several 3rd party libraries in one applications dead-simple, while it was non-trivial to use multiple large 3rd party C/C++ libraries at the time.
It scaled better in codesize, and performed better, than perl.
So java won over C/C++/perl in terms of (complex) web-servers. Later on, php cornered the simple end.
[link]
From: Cedric (Oct 01 2009, at 22:20)
The main thing that pushed Java in the spotlight is applets.
I'm not even kidding.
Sure, the easy syntax helped, but the concept of applets got everyone extremely excited since except for ActiveX, there was no real way to add dynamism to the sad HTML pages of 1995-98.
So everyone boarded the applet bandwagon and by the time that train crashed, the JDK had gone up a few versions and not only was the language and its libraries much more solid, a few back-end applications written in Java started emerging.
The rest is history.
[link]
From: Andrew (Oct 02 2009, at 04:36)
What is funny from the article and contributions, is the list of positive features keeps growing and growing.
Another one worth mentioning is that a clear semi-formal language/vm spec was available - the impact of this was felt by the number and solidity of tools and IDEs.
Try making a good IDE for c, c++, perl or python and you fall afoul of lack of static resolution or sheer language complexity. Oh and the lack of a pre-processor really helped there too.
[link]
From: Erik Engbrecht (Oct 02 2009, at 06:13)
I'd like to add that Java lacks any sort of language-level metaprogramming system and has highly regular, inflexible syntax.
To get Java, you basically take Smalltalk and remove all of the powerful concepts from it while leaving in the benign ones that everyday developers use.
I think there's something to be learned from that.
[link]
From: David Megginson (Oct 04 2009, at 10:34)
Andrew touched on a hugely important point: the Java VM. Because people wrote compilers for many languages, using the Java VM and libraries did not require using the Java language. That was, and still continues to be a win for Java.
Tim talked about libraries in general, but for me, the most important one was the java.net library. It looks obscenely over-complex to me now, but in the mid-late 1990s, it was a revelation in simplicity.
The huge range of testing, code-auditing, style, etc. tools still has no competition with any other programming language, and Eclipse's Java support is hard to give up when moving to Java's competitors (even within Eclipse). Just about every language has a *Unit app now, but it started with JUnit, and the language is still very-much intertwined with the agile, test-first culture. I find a lot about Java frustrating, but it's far too early for Java's obit.
[link]