I found most articles on the subject very confusing. But from what I read, the commercial features in the Java SE download are behind a very obvious flag (UnlockCommercialFeatures), which should avoid accidentally using those features without knowing it.

The definition of "general purpose computing" is confusing to me, I've no idea where full computers/desktops that control specific devices would fall under this definition.

They could also not include the commercial features in the standard download and make you download additional stuff to use the commercial features as they do with the Unlimited encryption packages.

Yeah, but what does "CommercialFeatures" mean? How much do each use of each function costs you? If you are already paying for standard Java support, wouldn't you assume it includes these features?

Also, one particular company with tens of thousands of installations was hit by Oracle lawyers because a software they bought from third party had for some reason this flag enabled.

I think "Commercial Features" is pretty much clear enough, especially since the Oracle paid features aren't really kept in secret.

What extra functionality does it include?

I'm finding this confusing as well. I write some Java programs for my employer. I just use the SDK/JDK. Most of what we do is use apache came, with spring and apache httpclient with some other non-oracle libraries for processing json or xml.

How do I figure out if we are at risk? We use the apps in-house only.

As was said above - figure out if your IT department is enabling that flag when running your java applications in production.

What do you do if you run commercial code?

The only thing you should really ever do if you have legal concerns: contact legal, and only legal, immediately in a way that preserves attorney-client privilege. If you have concerns about personal legal liability, then contact your own lawyer.

Openjdk is fine for commercial applications. If you have commercial code openjdk will work fine. Just make sure that flag isn't enabled.

Openjdk doesn't have all the same features as the oracle jdk (javafx etc)

Honestly, we need to just fork Java away from Oracle, just like Solaris and ZFS have been done.

I find it deliciously ironic that Oracle's products are no longer compatible with Solaris and ZFS because they won't follow upstream... because they don't understand they aren't upstream anymore.

Java needs the same treatment.

OpenJDK has about ~750 contributors with more than half associated/employed or sponsored by Oracle contributing to most significant part of JDK.

It is about 1M+ lines of highly optimized C/C++ code and 4M lines of Java code. So it is not like a package or a library that a dozen or contributor manage well. And Considering payment is the core issue here I do not know how highly paid people will be made to work on JDK.

> And Considering payment is the core issue here I do not know how highly paid people will be made to work on JDK.

They will be employed to work on the JDK: there are plenty of companies that are already involved in Java and employ people to work on it outside of Oracle.

Hypothetically IBM, Red Hat, Google and the other non-Hotspot VM makers could band together and fork Java successfully - hell, a even a bank or 3 will want in on the action. They will have to name it something else and prepare for the inevitable epic lawsuit, but funding people to work in the JDK will nor be a problem.

I think all 3 you mentioned are spending not insignificant resources in other programing languages.

IBM sees future in Swift LOB apps and Go on blockchain related efforts. Also with open sourcing of their own J9 components they would be even less inclined to participate in OpenJDK fork or some such

Redhat sees Ceylon on apps side and with all this containerization thing going on, may be quite a bit of Go.

Google of course is betting big on Dart on apps side and Go on infra side.

For Banks I do not see any issue at all to either pay Oracle or Azul to get commercially supported JDK. Their main unique requirements are either high-perf GC(Azul) or high perf collections which they anyway write for themselves.

Red Hat still has a lot of money invested in the JVM ecosystem, see all the JBoss products. Ceylon also targets the JVM, so even if not Java The Language we will see Red Hat continue to support Java The Platform for a long time.

Indeed. And that will be excellent reason not to go on warpath with Oracle when so many of Red Hat customers look to run Oracle certified Java and other Oracle Enterprise products on Red hat systems.

> Google of course is betting big on Dart on apps side

Dart is dead (or at least dormant). Google is pushing MS'ss Typescript very hard with Angular 2.

Huh, never knew Ceylon was used in production by such a large player.

So 5 million lines or so in total? For some reason, I thought the JDK codebase was much larger.

Why exactly would we want to do that? OpenJDK is already the main branch/upstream/however you want to name it, most people just don't use it for various reasons. Maybe this will change now, problem solved.

Is the OpenJDK a drop in replacement for the Oracle JDK as long as you are not using the commercial features? I'd like to move away from the Oracle JDK, but I'm not sure what gotchas I'm going to run into.

Not 100%, for example JavaFX.

Hence why there is a parallel OpenJavaFX project.

Or GUI rendering code, hence why JetBrains has their own fork for those that don't want to use commercial JDKs on GNU/Linux.

It sounds like then, for server uses it is a drop replacement? I've run one of our spring-boot apps on the openjdk and it has worked fine. My fear is that there are some nuances that only become apparent at load or in certain edge cases. It seems like that's not the case, but I'll keep investigating.

> It sounds like then, for server uses it is a drop replacement?

Yes, and in fact OpenJDK is the reference implementation nowadays. You could also check out the IBM JDK if you want to move off of Oracle.

OpenJDK is still essentially Oracle-maintained. It's GPL, but you need to give them full rights to your contributions with a CLA: http://openjdk.java.net/contribute/

Do these issues effect clojure which use the jvm and can rely pretty heavily (depending on application/dev preference) on Java interop?

Not too sure. But I think it will as those commercial features are low level tools heavily dependent on JVM and JRE.

Sure and who will pay the Oracle devs on OpenJDK?

A response to thereg article from the Java Champions https://t.co/LCz8tyAMTE (see that on twitter)