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?
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.
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.
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.
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."
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.
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.
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.
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.
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:
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'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.
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.
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.
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.
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.
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.
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/
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.
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.
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.
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.
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.
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/