Ask HN: What's the worst Oracle can do to OpenJDK? | Hacker News Reader

Ask HN: What's the worst Oracle can do to OpenJDK?

155 pointsyaanoncoward82 comments

I've recently started a project using Java. From a technical perspective and after careful analysis of alternative technologies, for what I am doing it currently is the right choice.

But with the Google-Oracle lawsuit, Oracle laying off the Sun team, and my professional experience, I really have to convince myself building anything on top of a technology stack where they are such a powerful player.

I understand that OpenJDK is GPLed with class path exception, but is that enough? Could Oracle somehow sabotage OpenJDK into oblivion? What's the most probable steps Google, IBM and RedHat could take if Oracle pulls the plug on Java, or worse, plays some dirty legal tricks?

I know my concerns are vague but I wonder if people who know better could share their thoughts?

View on HN

The worst Oracle can do is to stop investing resources in improving it. There are wide range of other sources that you can get a JVM from. Ranging from big IBM, to smaller players like Azul (zing or zulu), RedHat, Excelsior, JamaicaVM from aicas and many more... Who would all be happy to take your money and the mindshare away from Oracle.

OracleJDK might be the no brainer install today for servers. But given any drop in commitment the community is large enough to continue by itself. It will slow down because Oracle puts a lot of money in JVM development so that would be a pity...

Oracle likes to use its lawyers, but only if they can actually win money. If someone can imagine how Oracle could make money out of stopping OpenJDK then I would be worried but I just don't see it. I sooner see them sueing Intel for using some patented trick in ICC to make their SpecCPU results look worse than not continuing to support OpenJDK as they have done today.

Their model is support JVM's for cash. Improve it internally ahead of the curve for making Oracle Cloud better than the other clouds and just get a foot in the door in Marketing materials and good will.

In any case the Java community is so deep and all encompassing that one does not see the giant jungle anymore. The hardcore VM community is much larger than those of Python, Bash or Ruby. With only JavaScript coming close in VM developer head count.

> Their model is support JVM's for cash. Improve it internally ahead of the curve for making Oracle Cloud better than the other clouds and just get a foot in the door in Marketing materials and good will.

It's quite jarring to see "Oracle" and "good will" in the same sentence.

I can see that but acounting wise it probably the right term. .. and seeing it acounting wise is probably the best way to look at large Oracle strategies.

Oracle controls the "Java" trademark. They can prevent OpenJDK (and any other implementations) from being able to call future major versions Java (or indeed JVM/JRE/JDK), simply by not publishing or not licensing future versions of the TCK. (Licensing terms for the Java trademark require an implementation to pass the TCK to be able to call itself Java.)

Just removing the word Java from the OpenJDK sources and documentation would be a huge endeavor. All the standard tools ("java", "javac" etc) would have to be renamed. It might also require completely breaking backward compatibility, because APIs are now copyrighted and the Java standard library packages are named java.* (and probably there are class and method names mentioning "java" too).

ETA: even ignoring copyrights on API, the trademark itself might stop you from publishing the not-Java standard library under the package java.*.

ETA #2: other commenters say it's allowed to use a trademarked word as long as it's necessary for compatibility. But it's not allowed to actually say you're compatible. Apparently. I don't claim to understand this, but law is not require to make sense, so this could be true.

Trademark and/or copyright can’t be used to block interoperability, see the Lexmark printer cartridge lawsuit where they embedded their logo into a MCU on the cartridge to try and block third-party cartridges.

And while, yes, one circuit so far has decided that API’s are copywritable the argument of fair use is still up in the air (unless the appellate court has finally finished that case, I haven’t bothered to check).

Also, Oracle and Sun before have continued to release OpenJDK under the GPLv2 (with classpath exception), giving an implicit license to the API with the worst case being an implementation needs to use the same license - it may not be able to call itself “Java” on the packaging but “compatible” probably.

Even if you ignore API copyrightability, it's impossible for a Java implementation to be compatible without using the word Java in very many places, including in the API. (Presumably trademark law applies to an API; I can't publish an API under the package name com.oracle, and similarly I can't publish under java.xxx). Also the whole tool system and the documentation of everything.

Removing the word Java from all docs and sources isn't nearly as easy as removing the name RedHat and making CentOS. And even if you do that you won't be compatible because all the existing tools and programs expect you to be called java.

As the parent poster explicitly said, trademarks cannot be used to block interoperability - since, as you say, impossible for a Java implementation to be compatible without using the word Java in very many places, then this means that you are allowed to use that word without permission.

I'm not entirely sure if you're actually prohibited from publishing a new API under the name of com.oracle.* or java.* (IMHO you can, but I'm not sure), but even if you're prohibited to do so in the general case, you 100% can name a package com.oracle.java.everything without any permission if naming it so is actually needed for interoperability, that's a legitimate use of a trademark that its owner cannot restrict.

> since, as you say, impossible for a Java implementation to be compatible without using the word Java in very many places, then this means that you are allowed to use that word without permission.

If this is true, then why did the Apache Harmony project have to close because it couldn't get a TCK license and so couldn't call itself Java or even Java-compatible?

Using the word "Java" in the human naming, branding, advertising material, etc is not required for technical interoperability and follows the usual trademark restrictions. Getting actual interoperability is protected, calling yourself compatible is a bit trickier.

Having a project branded "Magic Java Bean" with a class name com.mycompany.magicbean requires permission from Oracle, but having a project named "My alternative black magic drink SDK" with a classpath com.oracle.jdbc or java.something does not require any licence, if that particular name is required for interoperability.

TCK, despite "compatibility" in it's name, isn't required for compatibility in the legal sense (it's required to demonstrate compatibility, not as an unalienable part of any component that happens to be compatible) so it can be licenced (or not) however Sun/Oracle wishes.

Harmony didn’t shutter purely because they couldn’t license the TCK, but without a acceptable license to the TCK they can’t say they are a certified Java SE or Java EE platform. This meant they had no way to prove or verify compatibility, but they still continued to advertise themselves as an open source Java runtime environment.

Ultimately OpenJDK’s existence was what caused Harmony’s death, since the GPLv2 with Classpath Exception was a “good enough” license for the community (personal and commercial).

right on. they pretty much "own" the word. they went as far as suing starbucks for using "java ..." for one of their ice cream flavors. at least they are not suing Indonesia. not yet anyway :)

> they went as far as suing starbucks for using "java ..." for one of their ice cream flavors.

To clarify for other thread participants: that was an April 1st joke by InfoWorld. Oracle didn't really sue Starbucks.

https://www.infoworld.com/article/2623819/misadventures/orac...

> simply by not publishing or not licensing future versions of the TCK

Yup, already happening. Implement a JVM and open source it and try to ask for a TCK. They don't allow non-openjdk-derivative open source JVM implementations to license the TCK. So one could argue the worst thing that they (and Sun) do is to disallow a competing open source version w/ the same test cases.

Just removing the word Java from the OpenJDK sources and documentation would be a huge endeavor.

Is any project working to do this, ala Debian's IceWeasel?

Docker just did this but it didn't make a big splash.

Imagine Oracle's current business model goes downhill. Imagine Oracle has plenty of money remaining and asks "How can we monetize Java?" They will not ask Hacker News, they will spend potentially millions of dollars asking lawyers.

Given Oracle's past behavior with respect to Java, their general competitive model and their financial resources the answer is "Worse than you you or HN can imagine".

If you already have a significant investment in using OpenJDK, you may not have a choice, but otherwise there are other good technologies and you should avoid any JVM, JDK and other Java/JVM based technologies or languages. IMHO.

I agree in principle though I don't see that happening anytime soon.

But the point is: why should I use Java in 2017 when there are plenty alternatives around? Mindshare, maturity, and ecosystem are good reasons to choose Java still. But what's the point in Java bytecode or other compile-to-bytecode languages when the only ISAs left are x86_64 and ARM (this is also a problem I have with WASM). Back in 1996/97, there was a very real danger of MS operating systems eating the world, and Java was welcome as a cross-platform language (for me, it was very important to be able to continue developing on Unix). I'd say Java was successfull in preventing MS dominance on the backend.

In 2017, it's time to move on. Personally, I'm not into languages dominated by a single party, or having a single implementation only. So it's C and C++ for me, plus JavaScript for scripting.

But Java has been the go-to language for most of the time starting with the WWW boom in 1996, so the sheer amount of Java code means I don't need to worry about Java's demise. In fact, I'm fully expecting to do Java development gigs until retirement.

As a counter-argument, why NOT use Java? You have multiple free and open source implementations to choose from, and there’s a library on Maven Central for almost anything you’d ever want - and if you don’t like the language itself there are many alternatives to choose from.

> You have multiple free and open source implementations to choose from

Can you list them? By "implementations" I assume you mean a JVM and a stdlib? I am struggling to find non-OpenJDK ones that Java compliant (i.e. passed the TCK and give me confidence in switching).

Yeah, I goofed a little here - there is a fair amount of OpenJDK derivatives but any of the non-hotspot implementations currently maintained are proprietary (IBM JVM, Azul Zing) or useless for what one is likely looking for (Dalvik).

Where I'd recommend Java

- fat backends for eCommerce, eGovernance, etc. with deep business logic

- when developing on Windows and deploying on Linux (though I'm personally much more productive with Unix/Linux) eg. pjmpl's point

Where Java isn't great IMHO:

- must carry around a JVM and must have a JVM for the platform in the first place (so no deployment on the BSDs with first party support)

- desktop GUI apps

- web apps where you want to share front-end and back-end code

- environments where garbage-collected execution isn't desired (such as realtime apps or performance-oriented apps with special memory layout requirements)

- asynchronous, evented I/O (though Java has libs for it as well, yet not in mainstream Java APIs)

- environments where JITing isn't desired for security reasons (NoExecute segment bits)

- environments where single address space apps aren't desired (security isolation)

- realtime apps including high-frequency trading apps

- OP's point of becoming dependent on a potentially rogue party without necessity

Not an expert, but I thought that nearly all of high-frequency trading (and finance in general) was Java. They spend handsomely on huge heaps and controlled-allocation data structures.

I'm not an expert in HFT either, but know personally someone who's developing HFT apps in C++. I guess if your profit depends on milliseconds and lower, there's no point in taking chances with Java.

But Java is of course huge in all kind of financial apps, including settlement of HFT deals (eg. not on a critical code path).

A good example is that we usually always develop on Windows and don't care where the JEE server is running.

Windows, some flavour of UNIX,maiframe system bare metal, container, whatever, it doesn't matter.

> why should I use Java in 2017 ?

Properly implemented multi-threading, i guess.

When python will finally have proper multi-threading things will change a lot.

But quite honestly, it's been twenty years, and that Gil is still there, healthier than ever.

This seems right. Oracle already expanded the scope of legal action beyond what most of us imagined possible, when they successfully argued that APIs can be copyrighted. It's prudent to presume them capable of other unprecedented attacks.

I don't think they can do much to harm OpenJDK as it's GPL and developed by various parties and individuals.

What they definitely can do is start charging for Hotspot which would have a disruptive effect on the whole ecosystem. From my experience around 9 i 10 shops use Hotspot before any other JVM implementation.

They may also withdraw access to the TCK which would render alternative JVMs not suitable for organizations that heavily rely on standards and have strict policies in that respect.

Should this happen, I am absolutely positive companies like Azul, IBM or RedHat will step in and build a new (friendlier) open Java platform based on OpenJDK. Heck, maybe that would even mean resurrecting Apache Harmony.

I wouldn't be too much concerned about that in genereal. Oracle does not have absolute control over Java.

> Oracle does not have absolute control over Java.

Oracle does have absolute control over whether they sue anyone over Java.

So how did that play out in Oracle vs Google?

Google can survive being sued, win or loose.

HotSpot is a JIT engine separated in parts C1,C2. This is part of the OpenJDK codebase and part of OracleJDK, Zulu and RedHat's shipping OpenJDK version. The C2 hotspot layer might be removed in favour of graal[1] in the mainline over next years, but that is open too.

IBM has their own in J9 JIT infra which is also (being made) open source. [2]

Most shops use OracleJDK which is more habbit than anything else as the other OpenJDK derived versions such as Azul Zulu or the ones in RedHat cent-os are very much from the same branch and also pass the TCK.

[1] https://github.com/graalvm/graal [2] https://archive.fosdem.org/2017/schedule/event/openj9/

Oracle uses Java in its own products extensively: in fact the Oracle DB has the JVM integrated into it as a component, so they need Java to develop regardless of the details of how they do it.

Oracle can't really sabotage OpenJDK specifically. What they could do is take all development back in house. Oracle is the main contributor to OpenJDK so that'd effectively make future versions of Java closed source. However they aren't the only contributor by any means and presumably doing that would lead to a fork of the project. Red Hat contributes quite significantly already (ports, an entirely new GC engine) and I guess they'd become a rallying point. Probably a lot of Java engineers would quit and go join companies supporting OpenJDK. It'd cause a lot of disruption.

However, are they going to do that? Well, probably not. They've owned Java for years. In that time they've increased funding significantly and open sourced large new components that were not open sourced when they bought Sun. They've also sorted out Sun's management issues with the result that the project started moving again.

There's a lot of Oracle hate around due to their aggressive sales tactics and the Google lawsuit. But if you restrict your view to just the technical side of Java, they've not done a bad job. They got the project back on track, open sourced a lot of new code, they've got a solid long term technical roadmap with experienced engineers doing very professional work entirely out in the open. The design process isn't just open, it's done through the community process, so other firms have their say (see the recent Jigsaw hooha for an example). You can go take part in the design process of major new changes. Oracle's proprietary bits on top of OpenJDK are really pretty thin, I'd be surprised if they make much money from that.

Ultimately the question is, can you have something like Java without being worried about the owners? I think the answer is no. If you look at the alternative companies that might have bought Sun and continued funding Java, there'd have been maybe IBM, maybe Google, maybe Red Hat but probably not. Red Hat would have been the best but are they big and rich enough to have boosted funding to the level Oracle has? Even if Google had acquired Java, well Google has a shit ton of languages and frameworks all competing for internal attention. Whilst Google has a lot of code written in Java, it's not clear to me that Java would have won out for funding and executive attention in the battle of internal politics against Go, Dart, whatever. And of course there are lots of people who are worried about Google and the direction it's taking as well.

> in fact the Oracle DB has the JVM integrated into it as a component

So java stored procedures inside oracle?

Yes, since the early days of Java.

Microsoft has the same with .NET on SQL Server.

Cool. They already have PL/SQL though, so I'm wondering what's their motivation to adding a full jvm inside their process.

Back in the .com days they also had Perl.

Is also a way to extend the SQL languages, and to bring existing code into the server side.

Probably the worst I can think of is taking the Google Android playbook open with closed extensions then deprecate the open. You already see this a little bit with things like JavaFx in the Oracle distribution but not the OpenJDK. Sure you can build it yourself, but how long till we see extensions that are in the Oracle distribution that can't be built for the OpenJDK? Eventually it looks like Android where what is open and what people actually use are two different things.

> I understand that OpenJDK is GPLed with class path exception, but is that enough?

GPL v2 does not say that it is irrevocable. Oracle could throw a huge monkey wrench into OpenJDK by announcing that they are revoking the current license on all of the code in OpenJKD that they own and either no longer licensing it or licensing it on terms incompatible with the current license, and start suing people who continue using it as if it is still under GPL.

This would put us into legally uncertain territory.

Generally, non-exclusive copyright licenses that do not specify a definite duration and do not say they are revocable are revocable at will. They may be irrevocable if supported by consideration.

The key question here would be whether defendants can find an argument that there was consideration (unlikely) or a substitute for consideration (much more likely).

Another approach Oracle could take is not to try to revoke the license, but rather simply announce that they are no longer issuing new licenses. People who have OpenJDK licenses now can keep on using it, but anyone who comes to Oracle for a new license is told no.

Unfortunately, GPL v2 explicitly says that you cannot sublicense and when a licensee distributes copies their recipients do not receive their licenses from the distributor but rather from the original licensor.

If Oracle succeeded with this approach the consequences would be murky. Existing licensees would probably be able to continue distributing copies and derivative works, and their recipients would be able to use them, but those recipients might not be able to further distribute copies.

For those drafting future open source licenses who want to keep these things from happening with software under your license: (1) explicitly say in the license that it is irrevocable, and (2) explicitly say that licensees can sublicense under the same terms.

Of the major free/open source licenses, the only one I know offhand that does this right is Apache.

The GPL is not (easily) revocable. The license for any concrete version already published in OpenJDK under the GPL can only be revoked 35 years after that version was published. Even then, the owner must provide public notice 2 years before revoking the license.

Source: https://law.stackexchange.com/questions/832/is-a-copyright-l...

That's specifically talking about 17 USC 203, which is a termination right that applies to all copyright licenses in the US, even those that explicitly say they are irrevocable and were backed with consideration.

That a license is eventually revocable under 17 USC 203 does not preclude it being revocable under other circumstances.

The case law holds that a non-exclusive copyright license without consideration that does not say it is irrevocable is revocable at will. That's why nearly every case you can find where someone tried to revoke a non-exclusive copyright license turns into a case about whether or not there was consideration.

Google "non-exclusive copyright license revocation" and you'll find a few articles discussing some of these cases.

See also Rosen's book on open source licensing, available free online [1].

[1] http://www.rosenlaw.com/oslbook.htm

Thanks! This is an important problem I wasn't aware of. Googling shows a lot of different opinions and confusion about this; it'll take me time to get to the bottom of this.

If one takes seriously the idea that all FOSS licensed under the GPLv2 and other licenses that don't explicitly say they're irrevocable (as GPLv3 does) is at risk of being un-licensed at will, the whole ecosystem is at risk.

Can you please provide a case in which a gpl licensed item was revoked "at will". Since I am pretty sure such has never happened you could alternatively provide another case in which a piece of software was revoked?

I honestly don't believe that you can make such an offer allow man years of work to be built upon your offer, derive benefits for years based on providing such an offer and say sorry changed my mind.

Even if an unproven legal theory existed that would Theoretically justify this, it would end in 7 years of litigation during which the ecosystem would have collapsed.

They would own at best a billion dollar legal bill and 100% of nothing at worst a billion dollar legal bill and nothing to show for it.

Its hard to imagine that this is a real issue.

As far as I know, no one has seriously tried to revoke the license on software that they have released under GPL.

The cases involving non-exclusive copyright licenses that do not specify a term usually just involve a couple of parties.

> I honestly don't believe that you can make such an offer allow man years of work to be built upon your offer, derive benefits for years based on providing such an offer and say sorry changed my mind.

That would be the argument defendants would use. In particular, they would use that to argue that "promissory estoppel" applies.

As I noted, non-exclusive copyright licenses that do not specify a term are revocable at will unless there was consideration or a substitute for consideration. Promissory estoppel is one kind of substitute for consideration.

If I had to bet, I would bet that a promissory estoppel argument would work to save the license, at least for people who already have copies.

People using GPL v2 (or other free/open licenses that fail to say anything about being irrevocable) and who want to ensure that if someone else ends up owning the copyright they will not try to revoke the license should be able to do so by wrapping that base license with something like the following.

(Don't actually use this. It's just an outline of the general approach one could take, written quickly. A real license should be drafted by a lawyer experience in software licensing)

---------

0. This license is called the "No Backsies License for <base license>".

1. Licensor grants you an irrevocable license to <name of software> under the following terms and conditions.

2. This software is dual licensed under both this license and under <base license>.

2. You may copy, distribute, make derivative works of, distribute derivate works of, run, display, and perform the software according to the same terms and conditions specified in <base license> for those activities.

3. You may sublicense <name of software> to others under the terms of this license. Your sublicensees receive all rights to the software that you received from this license or from <base license>, including the right to sublicense it. When you distribute <name of software> or a derivative work of <name of software> to someone else, you automatically sublicense it to them under the terms of this license.

4. Licensor will provide a <base license> license to anyone who receives the software from you, directly or indirectly, under conditions that according to <base license> result in them receiving such a license. This license is provided automatically, with no need for the prospective licensee to notify or contact licensor or for licensor to take any action.

If those are your concerns get back to your project and get it finished. These issues shouldn't affect you

If it ever did happen the whole industry would immediately develop a migration strategy. I wouldn't worry about it.

Are you so sure your project will be successful? The odds are much higher that your project will not be successful and so the choice of technology doesn't really matter. If it is massively successful, you'll have the resources to work around any shenanigans. You could even do the unthinkable and buy a license.

> The odds are much higher that your project will not be successful and so the choice of technology doesn't really matter.

I'm very well aware of that. I wouldn't recommend anyone to give such what-if scenarios much weight in their technology choice without tangible concerns. Yet, Java is one of the few technologies where I find myself thinking about its legalese at all, so I wondered if others had the same thought.

I guess it's because there's now a good bunch of new programming languages that start to compete on Java's grounds and don't have such PR disasters like the Google-Oracle lawsuit.

To be fair: most of the technical reasons for me choosing Java are based on improvements that came to Java under Oracle's ownership.

I apologize as I wasn't trying to be negative by suggesting your project might fail.

You should always use the best technology choice (for a lot of reasons). There was a recent HN post about over-engineering side projects, and the top comment was (paraphrased) "Over engineering is the point of a side project!".

I think there is a counter if you want your side project to be successful, and that's to leverage as much technology as you can to make your MVP. Licensing costs don't change whether or not it's the best technology to solve the problem. That's why I wouldn't worry about it. There might be another promising JVM language you could use without the legal hassle, but if you've already determined Java is the best choice, the development costs of using something else will outweigh the legal costs.

The industry may develop a migration strategy immediately, but the Oracle lawsuits will stay. And very few organizations can afford a Oracle lawsuit.

Well, they already have the "-XX:+UnlockCommercialFeatures" command line switch which apparently costs money to use. They might move more stuff behind that flag?

As I see the main reason to use this switch is to be able to use Java Flight Recorder.

Any references that this switch is a paid 'feature'? And what other options are behind it?

Other than the name of the option? and the fact that this rather clearly spelled out in the OracleJDK binary license text? http://www.oracle.com/technetwork/java/javase/terms/license/... and otherwise documented at http://www.oracle.com/technetwork/java/javase/terms/products...

> Ask HN: What's the worst Oracle can do to OpenJDK?

Nice try, Oracle.

Wouldn't they shoot themselves in the foot by sabotaging the JVM? They seem to be taking a serious push at taking over the dynamic language space atm?

Never underestimate there ability to shoot themselves in the foot. I got offered a breakfast with Oracle the other day, and I said a very definite "no".

Correct me if I'm wrong, but I don't believe Oracle fired anyone related to openjdk... they fired some people related to Solaris.

The way I read it was that OP's concern about the Solaris firings was just one example of Oracle's general bad behavior, and their tendency to not only suddenly stop supporting products but actively working to extract money from or otherwise hinder open sourced products that they have some claim to.

Nobody mentioned patents yet, so: Go full patent-troll on users of OpenJDK. This would also sink the Java ship because nobody would dare depend on the graces of Oracle and their Java support anymore.

Oracle's Java patent grant doesn't seem very broad on the face of it, since it only grants patents that are "essential" and only those for implementing the "Java language specification".

"essential" would seem to exclude implementation technology like HotSpot/JIT technology, and "JLS-only" would seem to exclude a lot of the defacto Java platform that real world apps depend on.

So what's left is the GPLv2 implied patent grant, which more of a legal theory and is untested.

The worst thing they can do is keep on maintaining it so people still have to use it.

Nobody "has to use it". Furthermore several JVM languages are developing LLVM-targeting compilers like ScalaNative and Kotlin Native.

Isn't Java the safest language in that regard? The JVM is one of the few VMs I know with so many viable alternatives, both open and closed. The Google vs Oracle suit also means that they couldn't reattempt a similar claim, if it already went through all courts and list. Also, you'd be taken care of by IBM, Amazon and all the other massively dependent on JVM companies. So an alternative would probably present itself without you needing to spend a dime.

Other VMs are at similar risks, but would have less opposition, and no existing viable replacement.

If Oracle would do something very stupid, the facts are these:

IBM has a Java VM with - likely - iron clad licensing around it A patent portfolio regarding virtual machines that (at least uses to) be quite deep, and a database engine partially competing in the same market as Oracle.

Almost every large enterprise runs Java somewhere.

End result might be that Oracle gives away quite a bit of business to IBM while simultaneously angering the IT departments of just about substantial company on the planet, not a great strategy.

Not to retread on what you laid out but, why is java the one true choice for all of this projects code? If this project is just not that massive I’d say that it shouldn’t make much difference. But you’ve kinda specified a larger problem which is vendor lock in. I’d spend a little time thinking about what locks you in to that ecosystem. At least to have it on your radar, but that might inform design a bit if you’re really worried.

I apologize for not answering your immediate question (I think it might be quite difficult to predict what dirty legal tricks someone "might" pull in some uncertain future), but is your project really all that dependent specifically on OpenJDK? Or (if not) are you concerned that there might be some event in the future that will make running your code on any JVM (OpenJDK, IBM JVM, Oracle JVM, etc) impossible?

I'm less concerned about JVM incompatibilities and more about licensing terms.

In my opinion, you only own your technology stack if you can build the build systems of your product on your machines. I can do that with OpenJDK, and with Debian's apt-sources it is a matter of two command lines and waiting for the build.

From a glance at IBMs Java site I don't really find anything about their licensing. The Oracle JVM isn't open-source, nor is its JDK.

Let's be honest: the impact of most (including my) project to live or die with what Oracle does with Java in the future is marginal, in comparison to much bigger unknowns. Still I think that the big Java shops out there must have a contingency plan in mind, and I wonder if anyone could hint at what's their plan.

Oracle needs to be convinced to not be evil. #probablyjustapipedream

The worst thing Oracle can do to OpenJDK is kill it completely like Microsoft killed Mono by open-sourcing .NET coreclr and C#.

Oracle Java is based on OpenJDK. It's not a separate implementation.

Microsoft has not killed Mono. Mono runs today on more devices than ever (do not think Linux, think Unity3D and Xamarin Apps) and has a unique factoring compared to .NET Core. It is currently very valuable to MS. Yes, Mono's class library implementation and Compiler are dead. But who cares. The better implementation won there. But the factoring, the runtime and e.g. the linker are all major assets MS will not easily throw away.

Mono is no longer the dominant Open Source .NET version but more an alternative runtime for special use cases. And for server use cases, .NET Core is by many factors better than Mono (stability, performance, ...).

They can abandon OpenJDK and stop contributing any further updates to it, focusing on closed-source Oracle JDK. This will be enough to kill the project. This is exactly what has happened with OpenSolaris.

And, of course, Google or IBM can't take the flag and continue working on OpenJDK on their own, because patents.

The last part about patents is not true. The OpenJDK has a patent pledge in it. Google even started incorporating OpenJDK into Android to protect itself from the patent case. The whole patent case with Oracle was not about OpenJDK but about Dalvik / Harmony, Google's own Java-like implementation.

Harmony was an IBM driven project

Could you please point me where the patent pledge is? I can't google it, and its license is GPL2, which is not patent-protected.

The GPLv2 has an implicit patent pledge:

6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

In particular:

You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

Of course, whether it is enforceable may be a different question (IANAL).

Didn't Java go big around 95? When do the main patents expire? Or is the issue copyright around the language/APIs?

The comparison with OpenSolaris is invalid. Java is really useful and uniquely so. Solaris is an also ran.

Oracle's pulling out would not be enough to kill the project. Mozilla could easily take it on.

OpenSolaris was really useful and innovative, too. I am happy that ZFS and Dtrace found their way to Linux (though not without some issues), however, I would rather prefer the whole package.

OpenSolaris :: Linux NEQ OpenJDK :: C#/.NET or ROR or any other language + SDK.

Why would Mozilla take on OpenJDK? Mozilla's mission is about the web, and Java is no longer a major part of the web.

In terms of scope OpenJDK would be comparable to Mozilla's mission. So even if Mozilla didn't grow to take it on, a similar sized org could. The point being open source specific Mozilla pattern orgs rather than private corps.

The majority of the web servers where performance matters, run on top of .NET and Java.

If Java goes its spot will be filled in less time than it takes to think about it. The JVM used ideas from Self, and other "old" languages, its designers are still working on things, there are other people with knowledge and ideas, I'd bet a few dollars that the Steele pack could come up with a leaner and meaner VM right away.

The Java ecosystem isn't so much about Java the language as it is about the extensive mindshare, quality of available packages, portability and long-term viability etc. The JVM has been the go-to environment for a whole generation of developers, and even though I don't (primarily) target the JVM anymore, it's not going anywhere.

I may be in the minority here, but I think a monetarization strategy for Java maintenance (by Oracle and/or others) isn't completely unthinkable of.

For new projects, performance and other constraints permitting, I tend to use JavaScript (ES5 or even ES3) for its excellent portability, including on the JVM which has two quality JavaScript engine implementations (rhino and nashorn). A couple years ago, there were even Node.js-compatible web containers by Oracle and RedHat, though these are discontinued, unfortunately.

Reply on news.ycombinator.com