What does that mean? Compare Java to other open source projects of similar magnitude (and there aren't many; maybe only Linux, which is actually bigger). Linux is even more exclusive than OpenJDK, and just like Linux, companies with appropriate resources often make changes to the software even if those changes aren't contributed back (or contributed but not merged).
> and not enough people seem to care
People will care once many start to actually feel it. Oracle's interests are probably not aligned with mine, and may or may not be a cause for concern for me, but so far Oracle's actions wrt OpenJDK don't harm me at all. The investment in the platform feels to have only grown in the past few years.
> but the Java community cannot really do it
Why not? I think it most certainly can, but at this point there's not enough motivation to do it.
The current situation (OpenJDK open but not a realistic choice in most production deployments; Oracle JDK/JRE remaining as de-facto gold standard; a process that forces strict compatibility tests on any competitor) can be fine from a certain point of view, but in practice it means that Java is not a traditional community-led OSS program. Rather, it's a program where the OSS community helps a company improve their software. RedHat is not the only Linux build with significant marketshare, and I won't get sued if I write a different POSIX system.
> at this point there's not enough motivation to do it.
No there isn't, that's what Rhaman is saying. But what he's also implying is that the direction of travel has changed inside Oracle, and people outside do not seem to realize it. IMHO it's fairly obvious where things are going (you'll stop "installing Java", and only develop and deploy in the Oracle cloud or similar Oracle-sanctioned environments).
That is one interpretation; I can think of others.
> Do you think they wouldn't do the same against any Java fork with a realistic chance of supplanting their implementation?
I think they wouldn't sue anyone complying with their very clear, very standard OpenJDK license. Google, apparently, thinks the same, and has now decided to comply with the OpenJDK license, too.
> OpenJDK open but not a realistic choice in most production deployments
What? AFAIK, Google, Twitter and plenty other companies run their servers on OpenJDK. It is absolutely realistic for most production environments. In fact, Oracle's JDK differs from OpenJDK only in a few monitoring features.
> Oracle JDK/JRE remaining as de-facto gold standard; a process that forces strict compatibility tests on any competitor
That's just not true. The Java standard is the standard, OpenJDK is the reference implementation and one of the most widely deployed implementations.
> RedHat is not the only Linux build with significant marketshare,
Neither is Oracle's JDK. OpenJDK, IBM's JDK and Azul's Zulu all have good market shares.
> and I won't get sued if I write a different POSIX system.
Probably not, but you wouldn't get sued (or, at least no one ever has been sued) if you comply with OpenJDK's open source license. You may well get sued if you don't comply with Linux's open source license, too (which happens to be the same as OpenJDK's).
> and people outside do not seem to realize it
Perhaps, but what's the difference? If they start doing a bad job with Java (so far they seem to be doing fine work), the community will fork OpenJDK.
This is news to me. I'm aware there are differences, but "not a realistic choice"? Can you elaborate?
Lol, like that was a choice Google made freely, rather than something they were forced to do.
OpenJDK might be OK in many circumstances (as I said, requirements vary) but you might want to avoid that particular case study.
I asked for evidence for this bold claim, since many production environments I know are using OpenJDK successfully, under heavy loads and without crashing. So... evidence of your claim?
Hell, way back in the early 00s I remember having to use the JRocket JDK instead of the Sun one due to some weird corner case- so I am fully aware there are cases you can run in to that would necessitate one implementation over another. But calling OpenJDK unfit for production at this point in it's life is either FUD or straight lack of knowledge.
What are you running that OpenJDK seems to be so incompatible with? I've literally never had an issue with OpenJDK 7 or 8 and I've deployed applications that serve millions of requests per day in many flavors of OS.
When doubts started to appear 20 years ago, companies slowly moved their new projects to other stacks.
They are still around and have been updated to more recent versions, but it hardly matters to most devs.
Oracle being careless with mobile OSes support and bringing out stupid enterprise frameworks like Oracle Mobile Application Framework, has made people even go back to C++ for writing portable code for mobile OSes.
There's two ways to not care:
1. I don't care if it goes away, since who uses that stuff anyway? 2. I don't want to invest anything to further the project, but I really like using it and it's crucial for my business!
At this point I think the latter is the problem.
It is real open source. Its not a community-driven bazaar-model development effort, but that doesn't define "real open source" (its just something enabled by, but not required for, open source.)
phrased another way, which bits are missing that prevent an individual from compiling and running Java programs on the JVM using open source software.
* Oracle JDK has a different font rasteriser, maybe some other bits like sound are different as well
* Oracle JDK has Flight Recorder support (that's a commercial feature)
* Oracle JDK supports both C1 and C2 JITs on ARM64, AFAIK an open source implementation of this is coming to OpenJDK 9, likely Oracle JDK will keep the existing implementation
* Oracle JDK has additional commercial features like resource management [2] and application class data sharing
OpenJDK vanilla is AFAIK not TCK-certified. However there are TCK-certified OpenJDK distributions [3].
TL;DR: OpenJDK is fully open source
[1] https://docs.oracle.com/javacomponents/
[2] https://www.youtube.com/watch?v=0WZpmylHbFM&index=8&list=PLX...
- ARM compilers are different
- The Swing font engine used to be different
- Tooling that many devs depend on, like the Mission Control
- The AOT native compilers and tooling for embedded Java
Not an exhaustive list.
What Rhaman is saying is: the wide Java portfolio is dying because people are not making enough waves around the JCP to keep Oracle on the straight and narrow. Nothing to do with opensource, the JCP is a very different project from traditional opensource development.
The JRE has never been a "real" open source project, but rather a proprietary system that opened up enough to develop a caring community. The problem is that, at the moment, the interests of Java's owner are not aligned with the interests of such community, and not enough people seem to care.
This has nothing to do with Java being "open source" or not; in fact, a real OSS project would happily fork at this point (as it happened with OpenOffice), but the Java community cannot really do it. It seems pointless to debate the merits of OSS in a situation where there is no OSS; it's like saying "We supported Windows out of self-interest; but let's talk about the pros and cons of opensource...".