A couple of months ago, Oracle released its Java Evangelists from employment. Shortly after, a supposed former high-ranking official at Oracle claimed “planned obsolescence” as the motivating reason in .
The email, sent to InfoWorld on Tuesday by a former high-ranking Java official, claimed to feature details from inside Oracle. It said the company was becoming a cloud company, competing with Salesforce, and “Java has no interest to them anymore.” The subject line cited “Java – planned obsolescence.”
Oracle is not interested in empowering its competitors and doesn’t want to share innovation, the email further alleges. The company is slimming down Java EE (Enterprise Edition), but it also doesn’t want anyone else to work on Java or Java EE and is sidelining the JCP (Java Community Process). “They have a winner-take-all mentality and they are not interested in collaborating,” said the email. “Proprietary product work will be done on WebLogic, and there’ll be a proprietary microservices platform.” WebLogic is the Java application server Oracle acquired when it bought BEA Systems in 2008.
If half of that statement is an accurate representation, it is a pretty scary picture of Oracle’s mindset and plans.
Now couple that statement with a small handful of facts in relation to Oracle’s ownership in Java:
- Java the language, the JVM, and the Standard API are open sourced under the GPL license
- Oracle is the owner of that intellectual property per their acquisition of Sun Microsystems
- Oracle has shown it is willing to defend that intellectual property in costly legal battles - its lawsuit with Google over Android is evidence of that
- Per the results of that lawsuit, Java’s API cannot legally be copied/forked and be packaged or renamed to something else
- The Java Community Process is presently the only way that changes are allowed in to the core language and the Standard API
- In order for a 3rd party provider to actually develop their own implementation of Java and distribute it, they must be granted a license from Oracle, presumably by purchase
Finally, combine all of those facts together with the prospects that Oracle, the sole owner of Java:
- does not plan on evolving it in a meaningful way
- feels no need to evangelize its product to increase adoption and encourage new and novel uses
- finds it only useful as the thing that its other proprietary offerings are built on
Is that hyperbole? Yes, probably, but it is a logical conclusion if Oracle truly wants to put Java the platform into maintenance mode.
So what does that grim prospect mean for the everyday developer who works primarily on Java or on the JVM? What about a company that has committed to Java technologies to underpin their software infrastructures? What about an entrepreneur who is starting to write their first prototype or MVP for their software startup?
The answer for what all of this means is: “not much changes at all… for now”.
For the everyday developer…
Java is still one of the most widely deployed platforms and widely used languages in existence. By all first hand accounts I’ve heard from, this year’s JavaOne was still vibrant. Major infrastructures are still being built from the ground up on Java today today. Java is still swapping spots #1/#2 on the TIOBE language rankings list with C.
Doom and gloom speculation surrounding Oracle’s releasing evangelists is not going to cause a drop in Java or JVM language skills needed by employers today, tomorrow, or next year - and probably for a while to come. Even if the popularity of the Java language and standard API cools down, new languages are constantly being developed at faster paces on the Java platform and those more often than not come with their own APIs baked on top of, or in place of, the Standard API.
What about Oracle’s hold on distributing the very commonplace Hotspot JVM on which all of the above depends? Even if that dies down, there are companies like Azul that are willing to pay Oracle the license to monetize their own compliant JVMs - e.g. their commercial Zing and the free Zulu distribution.
For the everyday developer, this news is not anything to be worried about. Even in cases of developers who are unwise enough to bet their entire professional career on one platform (they shouldn’t - personal R&D time is a must for the true professional), the demand for skill and knowledge around the Java ecosystem is not going to go away anytime soon.
For organizations that have already adopted…
Much like the common developer, not much changes here either. Organizations that previously adopted Java in their infrastructures already made the bet on Java as a platform in the past for presumably good reasons that achieved goals of the business - even in the face of the platform being backed by the presumed “evil” Oracle or backed prior by the perpetually destitute Sun Microsystems. These rolled out systems that are helping achieve some business objective should never be candidates to be jettisoned solely for for committing the sin of being written on top of something distributed by Oracle.
Generally speaking the costs and risks of rewriting or replacing Java pieces found in non-trivial infrastructures anytime soon are entirely too high relative the reward. The reward in this case is the potential that the platform you move to will be vibrant enough in the future to ultimately reduce costs and increase business agility. Rewriting and replacing working systems is a perilous path - just look at . Even if an organization managed successful migrations, the reward may only be realized after multiple years.
Irrespective of that, one strategy that organizations that adopted Java can implement to future proof themselves from being stuck in a legacy system hell is that of shifting their architecture to be microservice based. A microservices strategy comes with its own benefits and costs, and is still largely being debated in the software development world as to when/where/how microservice architectures should be deployed. But for the specific concern of being wed to a platform that Oracle could let stagnate, microservices would at least allow the wary organization to replace, or at least isolate, in a piecemeal fashion services and components that are Java based.
What about for new projects?
If one is starting a new technology company or launching an internal greenfield project where Java might be a technology fit, this is where the debate should be had on whether to build on top of the Java ecosystem or not. That debate largely rests on the incurrence of technical debt. Such debt is going to be completely unavoidable when it comes to platform selection - the differences exist on what the payback of that debt looks like.
Choosing Java as the platform means receiving a presently healthy and large ecosystem on which to build where all batteries are included and there is a swath of resources in knowledge, labor, and products from which to take advantage. In exchange for this, the interest on technical debt from that choice is going to be realized in the form of having a platform which may not adapt to future technology shifts because its owner is uninterested in evolving it. You may be able to launch a healthy product offering now, albeit something that will generally be more expensive to build out, but may have saddled future business agility.
The other platform alternatives each have their own debts, but in short, they look much different. For instance:
- building on top of the node.js platform means having the debt of a substantially less stable ecosystem to build on top of, but one of that is also very vibrant, trending upward, may be evolving for a long time, and has a growing swath of talent to choose from already
- building on top of the Ruby (probably with Rails) platform means the ability pound out working infrastructures at a reasonably lower cost, but debt from that choice will be realized if and when when scalability is a concern
- You can build on top of the Microsoft/.NET ecosystem, which has a few of the advantages that came with Java (sans the OSS ecosystem, but that’s improving) comes with coupling yourself to the whims and fancies of another corporate software behemoth for the most part
… and there are others, but each of those sum up the tradeoffs one has to make.
In short, the choice to build on top of Java for a new project is largely a personal decision that has to be made. Should Oracle’s potential direction of ennui regarding the platform hold sway in that decision? It absolutely should. But that shouldn’t be the sole dealbreaker - especially if building on top of the Java ecosystem would increase the chances of a continuously successful launched product.