To download the installer you have to join Red Hat's developer program and agree to the terms and conditions[1] which state that the services are for "development purposes only" and that "using the services provided under the Program for a production installation" is a violation of the terms.

So presumably I can't distribute this installer to my users or even have them install it themselves for production purposes?

[1] https://developers.redhat.com/terms-and-conditions/

Additionally, it is delivered as an MSI, making it less usable.

I would also like a simple ZIP file please with no installer. I like to set up some software with an environment variable that points to which JRE / JDK that I want it to use.

Example Use Case:

One Windows OS. Several smallish Tomcat servers. Each Tomcat server has environment variables that point to the CATALINA_HOME (a base unpacked tomcat folder), and a JAVA_HOME which points to a JDK or JRE.

I can stop a tomcat service. Remove it from Services control panel. Change some environment variable pointers in a .BAT file. Re-add it to Services control panel. Then restart the service. Now that server might point to a different Java and/or different Tomcat release.

Similarly Eclipse. I don't "install" it. Just unpack it and create a shortcut to it's launcher. Set its configuration file to point to which of my various Java versions I want it to use -- including multiple vendor's implementations.

Red Hat: I don't WANT to "install" a JDK on Windows.

As a long-time Windows sysadmin: MSI is vastly superior to ZIP on Windows. You can do the things you're talking about w/ an MSI-based installation so long as the MSI was authoried to include "Properties" (variable substitution) for paths, etc. It's a little bit of additional scripting.

MSI are more usable for large deployments.

They integrate with windows GPO and it can be rolled out everywhere, among other things.

I do the same thing on Windows. I try to "install" as little software as possible, and just keep a directory that has all of my software and a few scripts to create start menu shortcuts, file associations, etc.

You should be able to extract an msi with the right msiexec command line switches.

I thought of that. I can often extract MSIs using 7zip. I was about to download until I read that it can only be used for development purposes. Apparently I have to agree not to redistribute it. No thanks Red Hat.

Elsewhere in this thread I discovered:

https://github.com/ojdkbuild/ojdkbuild

And I already knew about:

http://www.azul.com/downloads/zulu/

The more OpenJDK folders I have to test against (on both Linux and Windows), the better. Just change environment variables.

For most people an msi is superior, you can uninstall from the control panel and the files will be in the same place from one install to another.

No, I'm pretty sure there's no intention to restrict redistribution. The "services" refers to support, I think. I'll see what I can do to get this clarified.

Ditto, I've poked internally, hopefully we have a reply for you to clarify this soon.

I don't think "services" == the distribution. How else does that square with the GPL?

http://openjdk.java.net/legal/gplv2+ce.html

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

The "+ce" part of the URL refers to the classpath exception, which turns the GPL into something more like the LGPL - specifically this bit at the end:

"As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module."

Coincidentally when i tried that link ( https://developers.redhat.com/products/openjdk/overview/ ) yesterday it wasn't available.

there's also a github repository with openjdk 8 windows builds availabe as zip : https://github.com/ojdkbuild/ojdkbuild

The license on the Github repository seems much more reasonable:

OpenJDK binaries are released under the GNU GPL v. 2 with classpath exception.

Project icon is taken from Nuvola icon set, it is released under the GNU LGPL v. 2.1.

Build scipts are released under the Apache License 2.0.

Other sources and binaries in this project (cygwin, freetype etc.) are released under their corresponding licenses.

You can also get OpenJDK for Windows (with support) from Azul systems: http://www.azul.com/downloads/zulu/

Actually this is also the only easy macOS OpenJDK install solution I've found so far.

Check out https://github.com/shyiko/jabba

It's like nvm (for Node.js) but for installing JDKs.

On linux you can use your package manager + alternative system.

There is also Azul Zulu Homebrew cask available, but last I checked it was a couple of patch version behind.

https://github.com/caskroom/homebrew-cask/blob/master/Casks/...

I've been using their ZuluVM distribution for a few years, and I've been very happy with it.

direct download without any registration !

Interesting. In light of recent Oracle JavaSE licencing enforcement (MissionControl etc.) this will provide some safety from legal uncertainty.

And maybe redHat will also release a JDK6 build for Windows for the poor souls (cough) who are forced to deploy with good old JDK6 even though it is unpatched.

Given that those stuck on JDK6 tend to be large corporations with deep pockets (and often a policy requirement to have a commercial support contract for all their software anyway), I think that's precisely the part they wouldn't want to do for free.

Our use case is a proprietary app that still requires Java 6. Fortunately, OpenJDK 6 is still supported and security-fixed (well, backported patches) in Debian/Ubuntu.

OpenJDK 6 won't be around forever. I strongly advise figuring out an exit strategy for that app.

well, yes :-) It's an old version of Quova, an IP geolocator from Neustar. The new version is way better, but we can't be bothered rewriting the stuff that uses it until we have to.

Java 6 EOL should be your "have to". It will be easier to fix before you get a hard deadline, and it's easier to upgrade by one version twice than by two versions once.

Having been in environments that still needed to support JRE6 and be secure, the support contract from Oracle is actually not horribly priced and is actively fixing CVE's that are not available to the public.

I love OpenJDK. It hurts my soul whenever I see an open source project using proprietary Oracle APIs. Most recently I ran into this with Graylog. Great product, but it's unit tests won't run without the Oracle JDK.

We'd be happy to use OpenJDK, but few days ago we discovered a bug (feature?) that works differently in HotSpot - so we had to migrate our services to it.

OpenJDK is the HotSpot VM.

Oracle Java has patches for things that OpenJDK doesn't. That's the real bummer, as it causes behavior differences and makes migration away from Oracle JDK impossible sometimes.

Yeah, that's what I thought too. However I'm seeing different behaviour on these two vms with the same version.

Already been there :( the command line flags by default are different

You can do a diff using java -XX:+PrintFlagsFinal

An important win here is that we can now give our Windows-using developers the same Java on their PCs that we run on the live Ubuntu 14.04 servers.

(they get a Windows 7 PC from IT, which they can use as-is or load Linux onto, on a "you break it we wipe it" support basis.)

Note this does not include JavaFX/OpenJFX.

Primarily because Red Hat traditionally cross-compiles anything for Windows within their existing Koji build system, and Gradle is not in the RHEL or Fedora repositories because it's such a pain in the ass to bootstrap (you can often build Gradle 1.X with 1.X - 1, but not 1.X itself which makes trying to maintain the package a challenge in your own sanity).

If OpenJFX switched to Maven or Gradle, Inc. made their product less janky to work with it could easily be included in the OpenJDK packages - you can still just build it yourself and toss the .jar in the OpenJDK directory and it will work, at least.

Is there a way to download this without registering to red hat developer network?

oddly, it directed me to 'register' to download, but the download started before i registered anyway.

I wonder how Red Hat plan to monetize this?

This is for people who are deploying to RHEL. They'd be happy to sell you a RHEL support contract.

In case you don't know what this is all about:

Oracles Java contains a number of "commercial" stuff that costs money. So in theory, you could download the standard Java SE and run certain tools or the standard tools with certain command line arguments and suddenly owe Oracle a shipload of money. And I am talking a lot of money, like $40.000 for a single machine. And yes, they have started using SDK analytics to map potential "costumers" and sending them huge bills:

http://www.theregister.co.uk/2016/12/16/oracle_targets_java_...

Someone suggested migrating to OpenJDK which does not (for most parts) include these tools and have a more sane license. The problem is that OpenJDK does not come with a Window installation from a reputable source.

TL;DR: Larry Ellison needs a new yacht and since Google is not paying he is now sending his lawyers after ordinary folks who thought Java was free.

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)

I hope after Flash, Java is next technology to go...

Why? The JVM is awesome. Or are you just trying to be an edgelord with that hot take?

Maybe he means in browser Java Applets. But they are pretty much dead anyways.

They aren't supported in Java 9.

Yes they are. They're deprecated, but not gone.

Not that it much matters, since Chrome doesn't support the NPAPI plugin, and FireFox is expected to drop support early in the new year, leaving Applets an essentially IE only thing.

Hopefully Java WebStart doesn't go anytime soon, I still rely on that for OOB management on my servers without needing to boot Windows and use IE + the .Net consoles.

Java Webstart is the official way for applet alternatives, according to the Java blog.

And in Java, anything deprecated is never really removed.

Not paying attention to the JEPs?

http://openjdk.java.net/jeps/277

There was a session at Java ONE about a set of API that will be gone in Java 10 after this gets introduced in Java 9.

Good. It was one thing we always disabled in our deployment of JRE. One less vulnerable entry point for those who needed it on their workstations.

The JVM is great, Java, not so much. At least we have Clojure, Scala, Groovy and Kotlin.

Those languages complement Java on the JVM to varying degrees. Kotlin and Scala were built to progressively replace Java in a codebase. Clojure was built for the JVM as its first target architecture. Apache Groovy was originally to script Java code, e.g. tests and glue code. (Although Groovy was later repurposed as a Java replacement in Groovy 2, not many people use it for that.)

Agree with your assessment of Groovy. It made the JVM easy to use for simple scripting and served a really good purpose as glue language between big monolithic JVM software systems.

I haven't used it for awhile now, but I used to work on a serious Groovy code base. It's out of it's league now. Once Kotlin's scripting story gets rolling it should eat the rest of Groovy's lunch.

It is unnecessarily resource hungry.

There was an article the other day on HN about Golang compiler and work on its GC. (Garbage Collection)

As the article goes on, it becomes clear that a modern GC managed system is no simple thing. As you start to add all the choices and tuning you end up re-inventing the JVM runtime.

Any program of sufficient complexity eventually ends up having GC.

Java may be too resource hungry for trivial programs. For large programs Java is an industrial strength runtime platform. Or I should say the JVM is. You don't have to use the Java language. You can use a number of languages that compile to JVM bytecode.

How so?

Well you can certainly hope but the problem is a lot of backend systems and software is written in Java. This software cost a lot and also make a lot of money for companies. End users/ consumers do not interact with this software so there is even less motivation to replace that.

Java (or the JVM) is the Cobol of the 21st century. There is such a large amount of software written for it, representing such a large economic investment, that it won't be replaced anytime soon. That is the reason Cobol is _still_ around. It's why Java will be around for a long time.

Exactly my thoughts. Replacement, if any, would be in form of older institutions/companies themselves get replaced by new generation e-commerce/financial services/banks etc.

We need a billionaire to buy it, shut it down, and then sue everyone in to the ground who tries to fork it.

I would say Java is more comparable to C++. Language-wise the syntax of the two is similar, they came from around the same generation of languages, and they both have a prolific community and ginormous codebases. Also similar to C++, there are MANY different implementations and flavors, even entire languages built on the Java VM. By this measure no languages come close to C++ and Java.

While some new languages have prettier syntax and interesting constructs, Java remains a viable platform despite it's warts. I would guess more production code today (even new) is still written in Java or c++ than anything else.

Java gets a lot of flak around here but its really not so bad when you use modern versions (JDK 8) with modern libraries (Apache Commons or Guava). Even Eclipse is surprisingly good now, defying my expectations years ago that it would remain buggy and hard to use forever. I learned Java in the last year and it's now my favorite language besides c#.

Eclipse (and other modern IDEs) is the killer feature that most other languages don't have. (With the notable exception of C# and Visual Studio as the counterparts to Java / Eclipse.)

A large code base written in a language that does not have tooling to do automatic refactoring cannot be maintained for as long a time. Gets scrapped sooner and rewritten. Especially in dynamic languages. A dynamic language may be much faster to prototype and get your initial code base written. But just try maintaining it for ten years. Twenty. Etc.

What replacement do you have in your mind?

why?

The eradication of your "toy" languages will happen far sooner than Java.

I guess some more people that Oracle can fine.