Hacker News Reader

> The JRE has never been a "real" open source project

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.

Look at what Oracle is doing to Google for the sin of refusing the JCP process. Do you think they wouldn't do the same against any Java fork with a realistic chance of supplanting their implementation? The details are not important, they'll throw the book at you and find something that sticks.

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).

> OpenJDK open but not a realistic choice in most production deployments

This is news to me. I'm aware there are differences, but "not a realistic choice"? Can you elaborate?

I think openjdk is used in production. It's even going to be used in android in the future. You are incorrect that openjdk is not production ready today.

I didn't claim it wasn't production ready, the parent post did.

> It's even going to be used in android in the future.

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'm going to be blunt: you claimed "OpenJDK [is] not a realistic choice in MOST production environments" (emphasis mine).

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?

Can you elaborate on why OpenJDK is not suitable for production deployments? I thought Oracle's JDK/JRE were based on OpenJDK's, with only minor changes.

Obviously it varies depending on requirements, but my experience is that openjdk tends to be a crashfest and/or end up being incompatible with a lot of stuff out there. The Oracle JDK/JRE invariably Just Works. It might be all a cargo-cult phenomenon (i.e. devs still testing only with Oracle builds out of tradition etc etc), it might be that Oracle have fabulous build tools not seen elsewhere, I honestly don't know; this is just what I see.

I used to experience random crashes with the OpenJDK several years ago, but haven't noticed that recently. Are you still seeing those issues or did you give up some time ago based on the aforementioned crashfest and haven't tried it in the last couple years?

One thing about OpenJDK is that the debug symbols are freely available so you can try and create a core dump and analyse why the JVM crashed. You can't do that with Oracle's or IBM's JDK AFAIK.

It's likely and believable that the different flavors seem to run at different speeds with different architectures. I also wouldn't be surprised to find the Oracle implementation to always be faster. I have a real hard time believing that OpenJDK has some huge flaws that prevent its production use as a blanket statement.

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.

On ARM the Oracle version is considerably faster than OpenJDK.

> for the sin of refusing the JCP process

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.

I went through a similar experience with Clipper and Turbo Pascal/Delphi, both were widely used and we thought they would last forever.

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.

> 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.

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.

> The JRE has never been a "real" open source project

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.)

would someone mind explaining, or linking to an explanation, of what bits of Java are open source, and which aren't?

phrased another way, which bits are missing that prevent an individual from compiling and running Java programs on the JVM using open source software.

- Some parts of tha JavaFX pipeline are different

- 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.

OpenJDK is fully open source. Oracle JDK is built on OpenJDK but changes a few things here and there.

* 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...

[3] https://www.azul.com/products/zulu/