The Future of Java: forking, death, or stasis
It’s popular nowadays to complain about the state of Java. What is the right approach for the future of Java? I’d like to outline a few possibilities, along with starting a discussion of the benefits and problems associated with each.
The first option is to stick with the status quo: Oracle controls the Java language specification, strong-arms the JCP, and rigorously defends Java and its revenue streams through legal action and licensing of compatibility testing kits (in addition to selling products based on Java, of course.)
This isn’t a horrible option; after all, it’s likely to give us a new edition of Java in 2011, with another planned release in late 2012. It’s also fairly close to what the Java community is already used to from Sun, although Oracle is far more aggressive about defending its territory than Sun is.
None of these are bad: Oracle’s willingness to pursue revenues means that the parent company of Java is likely to remain strong (a quality Sun lacked), and Oracle’s continued consolidation of Java technologies means that it has a large umbrella of Java expertise at hand.
However… some of those same features work against Java. Oracle’s swallowing of Java-using companies consolidates technology, but also means that competition is lowered; Oracle’s corporate culture implies a high cost for dissent, and what’s good for Java is … defined as what’s good for Oracle, whether the wider community agrees or not. (Oracle’s acquisitions consolidate technology but not necessarily expertise – because their retention rate for acquired employees is horrible.)
Others have suggested forking Java, thus potentially creating another VM spec (or perhaps just another language that leverages existing JVMs). Changes that went into Java would be mirrored in the new language, as community demand required, while the community could make changes that might eventually find their way into Java through mere market pressure.
This would remove Java (or, if you like, “Fava,” or “Lava,” depending on your appreciation of Hannibal Lecter or Indonesia) from a single vendor’s control, and the community would have more freedom to innovate.
However, there remain problems of patent; Oracle’s pursuit of Google indicates that any external source using Oracle IP might be endangered. It’s the same problem Mono has with .NET; it becomes survival with the approval of someone else, which isn’t a comfortable feeling (unless your name is Miguel, perhaps.) There are also problems with external viewpoints: people who’ve been whining about Java’s strength in the political arena will finally be truly enabled by such a schism between Java and Mava. (It’s “mavalous, dahling.”)
Another possibility – one suggested by Oracle itself before it acquired Sun – is the formation of a truly independent consortium, made up of independent yet interested parties – much like one could have imagined the JCP being, if Sun had no veto power. (In fact, this is the vision Oracle had for the JCP before it bought Sun; odd how its perspective has changed with the acquisition.)
This option has a lot of support: Oracle used to support it, IBM would support it, so would most developers. This option has the best long-term future, as it protects Java from an overlord, and allows the most innovation through competition as long as a logical arbitration facility existed (to prevent deadlocks in committee.)
However… it requires that Oracle allow Java to be freed from its control, an unlikely event indeed. Plus, arbitration is going to cause friction, especially if larger parties’ wishes are not respected. (Imagine a feature that Oracle and IBM support, but no other committee members desire; Oracle and IBM would resent such defiance, and neither are known for accepting defeat.)
The last possibility is one that more developers support than we care to acknowledge: defeat and abandonment. With a single vendor controlling so much of Java, perhaps it’s time to move on to a different viable alternative: perhaps Google Go, or Python, or Ruby are strong enough (or can be strengthened enough) to replace Java outright.
This possibility gives a lot of freedom; it’s not like Ruby and Python have few supporters, and the influx of new blood (especially when the new converts are more used to scalability than the normal Python or Ruby developers) would probably help Ruby or Python immensely.
Plus, this isn’t a new concept: many prominent Java developers have advocated abandonment of Java, viewing it as a legacy environment only (“I use Python when I can, and Java when I have to – often, just to run Python.”) Perhaps this approach is more viable than was thought.
However, it does mean abandoning what Java does well – and Java really does quite a bit well. Further, part of Java’s problems come from being as successful as it is – and it’s not known if the convergence of a Java community and another language’s community wouldn’t replicate Java’s problems.
In addition, we Java developers have gotten used to a certain level of performance – not in one-off command-line programs, but in environments where Java excels at heavy lifting. Shifting to other languages means giving up some of that performance edge, which might not be so comfortable.
So there are four alternatives: the status quo, forking Java, creation of an independent consortium, and total abandonment. The problem with considering what the alternatives might be to the status quo is, quite simply, that Oracle most likely does not care, nor do they have any reason to care. We can protest all we like that we desire an independent controlling body, but there’s no reason for Oracle to do anything but nod at us… and ignore anything they don’t like
