
Ask HN: What's the worst Oracle can do to OpenJDK? - yaanoncoward
I&#x27;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.<p>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.<p>I understand that OpenJDK is GPLed with class path exception, but is that enough? Could Oracle somehow sabotage OpenJDK into oblivion? What&#x27;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?<p>I know my concerns are vague but I wonder if people who know better could share their thoughts?
======
jerven
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.

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

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

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

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

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

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

~~~
danarmak
> 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?

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

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

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

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

~~~
tannhaeuser
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

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

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

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

~~~
a3n
> Oracle does not have absolute control over Java.

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

~~~
bitcharmer
So how did that play out in Oracle vs Google?

~~~
a3n
Google can survive being sued, win or loose.

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

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

So java stored procedures inside oracle?

~~~
pjmlp
Yes, since the early days of Java.

Microsoft has the same with .NET on SQL Server.

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

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

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

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

~~~
danarmak
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...](https://law.stackexchange.com/questions/832/is-a-copyright-
license-by-default-revocable-or-irrevocable)

~~~
tzs
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](http://www.rosenlaw.com/oslbook.htm)

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

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

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

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

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

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

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

~~~
moondowner
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?

~~~
jerven
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/...](http://www.oracle.com/technetwork/java/javase/terms/license/index.html)
and otherwise documented at
[http://www.oracle.com/technetwork/java/javase/terms/products...](http://www.oracle.com/technetwork/java/javase/terms/products/index.html)

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

Nice try, Oracle.

------
bigleagueposter
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?

~~~
chris_wot
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".

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

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

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

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

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

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

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

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

------
twelve40
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?

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

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

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

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

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

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

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

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

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

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

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

