A couple of weeks ago, I detailed the major features we can look forward to in Java 8 [1]. What I didn't say was that .Net has most if not all of those Java 8 features, as well as many other features deferred to Java 9. I'm not a big fan of adding everything but the kitchen sink to the Java language [2]. However, I think the Java platform (as opposed to the language) should evolve to support these features. I also think .Net is a great technology, and C# and the .Net platform accomplished in many ways what they set out to do, which was to become Java 3. My biggest misgiving is that I've never liked Microsoft's operating system, and I loathe bugs I can't -- in theory -- fix.
A tale of two platformsYou could make the claim that with a smaller install base and a greater willingness to rip the rug out from under developers, Microsoft can afford to move more quickly. Some of that is fair. I remember in the '90s and early 2000s, Microsoft decided we needed to change database APIs almost weekly from ODBC, RDO,
ADO, to OLEDB and so on. Yet with .Net, Microsoft reached a kind of critical mass, and the faster progress has continued.
ADO, to OLEDB and so on. Yet with .Net, Microsoft reached a kind of critical mass, and the faster progress has continued.
[ Also on InfoWorld: Love and hate for Java 8 [3]. | Think you know Java? Test your programming smarts in InfoWorld's Java IQ test [4]. | Master the latest in Java development with our JavaWorld Enterprise Java newsletter [5]. ]
But how did Java fall so far behind? The early days of Java were fast paced. From Java 1.0.2 to Java 1.1, we saw radical (and often incompatible) changes in only one year. Going from 1.1 to 1.2 took 1.5 years, and version 1.22 -- a more important release than its number suggests -- arrived a mere 7 months later. Just 10 months after came the pivotal release of Java 1.3; this was the first release with a garbage collector that had the server side in mind.
Java 1.4, which brought us NIO and
regexp, dropped in less than two years later. Java 1.4.2, which brought us garbage collectors for multicore environments (though not very stable ones), came out another year on. Yes, Java 1.5 made parallel and concurrent GC ready for production, and it added important concurrent and NIO features, but it took one more year.
Overall a good performance release, Java 1.6 made locking cheaper, but it was nowhere near as substantial as 1.5, and it required a two-year wait. Java 1.7 was the first major change to the underlying VM technology (the G1 collector) since 1.4.2, and it gave us
invokedynamic to better connect other languages on the JVM. However, as the major releases drifted from one to two to nearly five years apart, the pace was clearly slowing.
Sample features in Java and .Net and their release dates
| Java feature | .Net or C# feature | Java version / release date | .Net or C# version / release date |
|---|---|---|---|
| java.util.concurrentFuture [6] / ForkJoinPool [7] / java.util.stream | Task Parallel Library [8] | Java 5 / Sept. 30, 2004 Java 7 / July 28, 2011 Java 8 / April 2014? | .Net 4.0 / April 12, 2010 |
| Lambda expressions [9] | Lambda expressions [10] | Java 8 / April 2014? | .Net 3.5 / Nov. 19, 2007 |
| Strings in switch statements [11] | C# switch [12] | Java 7 / July 28, 2011 | .Net 1.1 / April 24, 2003 |
| Generics [13] | Generics [14] | Java 5 / Sept. 30, 2004 | .Net 2.0 / Nov. 7, 2005 |
| NIO [15] | Asynchronous I/O [16] | Java 1.4 / Feb. 6, 2002 | .Net 2.0 / Nov. 7, 2005 |
| Jigsaw [17] | Assemblies and application domains[18] | Java 9 / ? | .Net 1.1 / April 3, 2003 (subsequent incremental improvements) |
Why did progress slow?There's a simple explanation for Java falling off the pace: Sun was not a healthy company. Java was born in the dot-com boom when Sun was selling Sparc boxes left and right. Meanwhile, the cost of Intel/AMD came down, but the price of Sparc didn't. Despite the excitement around the T1000 and later platforms, the economics weren't there. (Sure, the late-model Sparc is more efficient, but the price is so freaking high that I might as well power my data center on mahogany and endangered species rather than pay the premium for the hardware. Even if our legislators passed cap and trade, I could buy a small rainforest worth of carbon credits on the cost difference and theoretically make up for my excess power usage.)
Then the dot-com boom went bust, and Sun decided to pursue "commodity" computing in its hardware business right as the big iron clusters were being built. In short, Sun made the wrong bets in its hardware business.
Sun was great at creating ecosystems; it just couldn't create products that businesses wanted to buy. Its eventual suitor, Oracle, is great at burning ecosystems to the ground, eating or destroying all of the companies that play in them, and creating highly profitable products to replace them.
Oracle acknowledged some of the business and political issues that delayed Java 7 in one of its classically terse public statements [19]: "We all know for various business and political reasons that this release has taken some time."
However, we have to look beyond Sun's financial troubles and examine the system surrounding Java. Because Sun went back on its word to submit Java for standardization, it created its own "standards" committee called the Java Community Process. Originally it was a sort of smoky backroom star chamber. Over time, it opened up to some degree, but Sun and now Oracle, with absolute veto power, ignored the rules [20] and did whatever they wanted.
What's been holding back the JCP? It's not openness -- it's competing interests. Although I sat on the sideline and ate popcorn, I remember the three-letter vendors participating in EJB3 back in the day. They contributed delays and procedural concerns. Why? They needed to buy or develop a product to integrate into their app servers. If the next JavaEE spec came out, they didn't want to be late to market if they could help it.
It's difficult to coordinate a product release in one company, let alone several. Luckily, with consolidation this may get easier. I don't think the JCP contributes the largest part of the problem for Java.
Separate the Saucer SectionToday, Sun is a memory and Oracle is the boss. Yet why do Java releases still take so long? The simplest explanation is that Java is too big. Big projects tend to go slow and are fraught with risk. To solve this problem, let's look at how Java could be smaller.
First, Oracle has to get over its crush on client-side technologies. Sure, there isn't much in Swing or Oracle's anointed successor for it, JavaFX, that can't be done in a modern Web browser with fewer problems, but Oracle needs you to be tied to its platform -- at least it did.
It isn't clear to me what real advantage JavaFX or client-side Java strategically gives Oracle. It seems like a technology that would have been designed to compete with VB6, Flash, or some 4GL thing. In a modern, BYOD, multiplatform environment where every up-and-coming exec thinks he's cool 'cause he takes notes on his iPad with his finger, this stuff doesn't mesh. Why do we need the client side holding back the server side? It seems like we could have fewer security delays and reap the PR benefit of not enduring months of "Java zero-day security problem [21]" and "how to disable Java [22] on your computer" headlines.
However, that breaks off a de facto deprecated but over-invested technology related to a bygone vertical technology platform play that should frankly be taken out to the barn and shot in the head. It doesn't solve the biggie. Maybe Oracle could even add it to its other misadventure, Java ME, and call it Ordroid. If Oracle bought BlackBerry and moved it to that new division, it would have "the platform of the future" and an "iPhone killer" for a quarter or two before investors called their bluff.
Quite simply, Java the language is no longer as important to Java the platform as it once was. The second most obvious seam that should be cut is the one spliced by Microsoft in the beginning, even if it has in practice coordinated releases after 2007. Cut the Java language from the Java platform, and release it on its own schedule. This would be easier for Oracle -- the development tool it produces isn't a major part of its Java-related business and isn't used by a large percentage of Java developers. Microsoft has to coordinate Visual Studio version X with the next release of .Net and C# for marketing reasons. Oracle really doesn't.
Java the platform has multiple languages ranging from JavaScript to JRuby to Scala to the more esoteric. Moreover, supporting these various technologies in a performant and scalable manner is important to the cloud. If the cloud is the future, Java the platform and Oracle want to be there first. At the moment, Java and Oracle are there by default. Anyone else -- well, the most obvious way to support Ruby, Scala, and possibly even Node.js is the Java platform. However, the Java platform currently seems to be more of an anchor than an engine of their innovation.
I trust Charles Nutter (JRuby/Red Hat) and Martin Odersky (Scala/Typesafe) to decide what goes into the Java platform more than I trust Mark Reinhold (Java SE spec lead/Oracle). I mean no disrespect to Mr. Reinhold, and there's some evidence [23] that a lot of collaboration is happening, but waiting on the Java language or some pet project at Oracle to need it holds back progress.
It's been a rocky year for Oracle's leadership of Java. A lot of Sun's decisions have come back to haunt us. My take (if you haven't figured it out already) is to spin out client-side Java, separate the release cycles of the JVM versus the language, and focus on Java as a platform rather than everything at once.
This article, "Java faces tough climb to catch up to .Net [24]," was originally published at InfoWorld.com [25]. Keep up on the latest developments in application development [26] and Java [27], and read more of Andrew Oliver's Strategic Developer blog [28] at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter [29].
Comments
Post a Comment