Is this actually a trap? The "trap" page has a huge warning section that clearly tells you license has substantially changed and how to get open JDK, and what license it has.
> With JDK 11 Oracle has updated the license terms on which we offer the Oracle JDK.
The new Oracle Technology Network License Agreement for Oracle Java SE is substantially different from the licenses under which previous versions of the JDK were offered. Please review the new terms carefully before downloading and using this product.
> Oracle also offers this software under the GPL License on jdk.java.net/11
This information is either deliberately or accidentally missing in the post. If we assume the author did his research before writing this piece, I can only believe this was done with purpose.
Not everybody reads warnings. Many will go to that page and just go straight to the download. In addition, the warning doesn't say "not for commercial use" - you have to click through and read a long legalese to find it. Oracle could still choose to make it clearer...
Oracle is notorious for auditing compliance with their database licenses, and shaking down their users for extra money in the event the auditors find something even slightly questionable. There are external consultants that make a pretty good living just preparing companies to withstand those audits.
They haven't been doing that with JDK licenses, so far -- as long as Java had licenses which didn't allow for this kind of gamesmanship. But now that the license has changed, it's a completely legitimate thing to get worried about.
Not sure where you live or what sort of company you work for but in my country & our company we cannot just have a fuck all attitude towards software licenses.
The USA and I've been doing it for two decades, honestly copyrights and licenses are not important to me. I have taken a fuck all attitude without consequence and will continue to do so forever.
Haha, I’m not playing that game because I’m lawsuit averse but I’m not surprised people are successful at it. This JDK includes telemetry so it just got a lot more dangerous to play but otherwise I’d guess license violations are pervasive at small shops.
The moral argument that code should not be restrained by artificial license, like we treat ideas, is a strong one but not made clearly here.
If code was treated more like ideas or recipes we'd all still have jobs.
If you believe that strongly enough, civil disobedience through ignoring licenses is one approach. No one should risk more than they're willing to lose on the position because you will lose if it's costing someone else enough.
That won't work if your company goes through due diligence or ends up getting a licenses review from Oracle. You'll have to settle up then and it won't be cheap.
The Oracle license police live for situations like this.
p.s., If it's just personal use you are within the terms of the license.
The new license (https://www.oracle.com/technetwork/java/javase/terms/license...) is very clear. It states in plain English: "Further, You may not: use the Programs for any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating your Application;".
How is that not clear?
This entire article is just pure FUD. Oracle has stated over and over and over how the new licensing model works. It's clear to anybody who spends a couple of minutes reading the documentation.
If you want to claim that 2000+ word terms are not legalese then so be it. Suffice it to say, I disagree. What is needed here is a summary in the warning box on the main page. Something like "Do not download this unless you want to pay us".
You'd think it's clear, and yet I've joined projects where software with such terms was included in production builds because "it was downloaded with npm so it's open source."
And having a user certify that they read a license agreement. I'll leave it to lawyers to talk about whether a user actually agrees to a license when they run "npm install", but Oracle's site at least requires the user to accept the license agreement by physically clicking a button. And I've worked at a lot of companies that drill into you that you do not click that button without approval from legal.
I get your point, but npm has the same issue even if you didn't accept the license. I mean, if you didn't accept the license that it comes with, then what license gives you a right to use it at all?
IMO, there's an argument that you implicitly license others in making your code available in a package manager such as NPM which requires no authentication or license clickthrough to incorporate code in your project, unlike the .net or other PMs where license terms are presented and require click-through agreement.
Not saying anyone should stake any bets on that argument winning, just that it wouldn't likely be summarily dismissed in court and would at the very least factor into the damages calculation.
Will be interesting to see if any cases like this ever get adjudicated and precedent set.
What implicit license, though? GPL? BSD? Something else? I feel like developers have a tendency to gloss over these things as if all FOSS licenses are the same, but they really aren't.
What's unclear to me is how I would be running afoul of the licensing terms if I used the non-free version of the JDK to develop Java software. Because "developing, testing, prototyping, and demonstrating [my] Application" is exactly what I'd be using the JDK for.
Easy loophole, infinite open beta, continuous integration, rolling release. At which point, with which release would it turn from beta to commercial full gold master? Slippery Slope that. A better wording would be "if you make money, we want a cut, or you get a cut, got it?"
Not a lawyer either, but the license says that the "Programs" (meaning the JDK) may only be used for these purposes. Once I write my application, it will be running on the JRE, not the JDK.
Iirc there is no jre in 11, just jdk, also Oracle is not dumb they likely have a clause covering your "loophole". Finally why would you develop on Oracle jdk and run on open. Seems like an easy way to get bugs.
The majority of people don't download the JDK via this method (eg. a package manager) and will miss that big box about a license change.
Edit: Plus even if they aren't you still have the general mindset of "next next install close" where people are so normalized to getting something like that, to test or deploy it would be very easy to miss - given the license of the previous versions it would be an expectation that you would also be able to use the next version for commercial use also.
Although Oracle are perfectly within their rights to change the license, that doesn't mean it's not a dick move and a scummy thing to do.
Absolutely not. We are installing via a package manager the Oracle issued RPM for example. I would have missed the licensing story if Joda was not writing an article about it.
How is that possible? Are you going to the Oracle download page and downloading the RPMs? Are you specifically adding a repository that includes Oracle software?
There are certainly no default repositories that include this code. The whole point (and it's been this way for years) is that you can't download the Oracle jdk without clicking through a license.
New JRE/JDK gets released -> somebody from our company goes and downloads the RPM after accepting the license -> she uploads the RPM into our internal repository -> somebody from another department changes the build scripts to use the new JRE/JDK -> few minutes later we are running the dev clusters with the new JRE/JDK.
In this process the person who downloads the new RPM (aka me) has to be 100% sure that the new JDK is ok to be used. Which I completely missed (my bad) I was wondering about the GPL stuff a bit but I was thinking that Oracle came to their senses and started to distribute the JRE/JDK under a license that is better than the previous one. Again, my bad that I paid attention more to the performance improvements, modules, ZGC etc. than to the license changes. This is why I was surprised when I saw the article from Joda (his real name is Stephen?) and also upvoted, sent around to all my Java peers to be aware that this is absolutely, 100%, pure fuckery that Orcle just dumped on us.
Sounds like your company needs a better processes on how proprietary code is distributed internally. Most companies have a review process for thins like this.
The download page [1] has a large bold warning that the license terms have changed. What else would you like them to do?
Hmmm. At most you're mad because the bright yellow warning box that tells you specifically to re-read the license because it changed is not clear enough for you, even though apparently being sure about exactly that is your job.
I'm not sure you can blame Oracle for this. They could I guess give you a tl;dr summary in the box. But, how long would it take you to study the new situation? A few minutes?
I am not mad. I am thankful. And yes I am a ignorant engineer who cares more about features than legal crap. The only thing I am 100% sure is that I am not alone.
If you don't care about all aspects of your software, including security, ethics, and legality, you are not an engineer. Engineering implies professionalism.
It's debatable whether there are any true software engineers (we're certainly not licensed like traditional engineers), but all software professionals should be concerned about licenses. It's part of the job, as are all ethical considerations of your work.
It's fairly common to automate that stuff away, and not just for Oracle.
For example, if agreeing to TOS was neccessary, Let's Encrypt could no longer be "totally automated". Therefore certbot has an "--agree-tos" option, present in oh so many ansible repositories.
How do you automate that? You need some kind of cookie to download JDK and you're getting it by clicking a button. The only way to automate it is to simulate "agree" click.
I'm not saying I'd write an "I Agree" bot, but I've certainly written scrapers of comparable or greater complexity, and I'd be quite surprised if there was nobody that did this.
If you haven't written a bot, but you habitually download the JRE/JDK from Oracle's website, accepting the license manually each time, is there really a difference? How many people are rereading the license each time they do this? I would guess the number of people that do this is roughly a rounding error above 0.
The new Java has telemetry. Oracle will be coming for you. One of the reasons we don't run it is so we don't send them telemetry from prod... Nor so that we have a risk of the telemetry send breaking prod.
Everybody and your servers needs to keep mum about it or otherwise you'll get a call.
You think I'm making this up? I've worked at two places where we were in contact with Oracle police because they thought we used (more of) their software.
I think license changes are common enough that the reaction to such a thing is often "yeah, whatever." Most of the time, these sorts of things are not actually that substantial
So they're turning a well known product that was free for decades into an expensive enterprise offering. And you're saying that calling it a "substantially different" license is a warning?
In my book this is not a warning at all. This is clearly an attempt to mislead without breaking any laws.
And that's good that package managers ship only openjdk. When I migrated to Linux I didn't know better but as "openjdk" was easier to install than Oracle JDK I used "openjdk". It turns out it works very well, actually I can't tell the difference.
Unfortunately, many people add a repository with Oracle JDK to their package managers and install the JDK from there, due to some perceived better compatibility and/or extra bug fixes. (And in my experience, this is true for the Java plugin; the "official" plugin seems to work better than the IcedTea plugin.)
Confluence is an example of a piece of software that wouldn't run correctly at all under OpenJDK.
Even today on the Atlasian docs, they provide a Docker image of Confluence to evaluate, but if you buy a production license, you are required to build an OracleJRE Docker container (they provide instructions) for production.
It's been years and they still can't support OpenJDK ... it makes me wonder what weird proprietary crazy reflection shit they're doing in there.
Last time I tried to run Jira with OpenJDK, I stumbled upon some encryption algorithm not supported in OpenJDK. I didn't research further. But that was a long time ago, nowadays I bet that OpenJDK will work just as well.
The encryption algos are not supported with Oracle java either. The stronger algos have a separate licence and needs to be downloaded manually for either java sdk
On ARM openjdk has a lot of issues while oracle jdk/jre runs smoothly. Many apps will just crash under openjdk and if they run are much slower also on intel. It should be easy to benchmark this.
It is a reason why we moved to .net core entirely. I have nothing running Java anymore. Shame as I liked Clojure somewhat.
A few years ago, Minecraft simply wouldn't run nearly as good on OpenJRE, not even the server - it was several times slower. Not sure how it is today since I've stopped playing around 5 years ago.
I've seen issues with really minor difference in OpenJDK and Sun JDK, that forced people to stick with Sun JDK (like some library somewhere doesn't properly work with OpenJDK).
An interesting thing about AdoptOpenJDK is that it seems they may provide builds with DCEVM + HotswapAgent integrated, in the future [0]! And maybe become a very good and easy to use alternative to the way too expensive JRebel.
That's great news! Properly working code reloading would improve the development experience enormously.
Why wouldn't it be integrated directly in the upstream OpenJDK source, though? It sounds like it would be a separate patched build that I'd have to download, and wouldn't be available if I just "apt-get install openjdk-11-jdk" in Debian?
This is not new, and as per: https://www.oracle.com/technetwork/java/javase/terms/license... it was put in place in 2017 already. Seeing that the "LICENSE" of Java 8 simply points to their website, it means that they effectively changed it for Java 8 as well.
So that means that even if you're running Java, you have three options: (1) Continue using it illegally, it will probably be a low risk. This is not advisable especially for larger corporates. (2) Purchase JDK license (3) Switch to OpenJDK
The situation is confusing but not that confusing.
Java 8 has commercial features that are locked by default. You can unlock them by passing a command line flag that looks like -XX:+UnlockCommercialFeatures, so pretty hard to miss.
If you use those in production, you're meant to pay. But virtually nobody does use them. In fact Oracle open sourced them all for Java 11, perhaps because of that fact.
Now in Java 11 there are two JDKs, that are virtually identical. OpenJDK and Oracle JDK. The latter is the same as the former but commercially supported. If you use it in production at all, you're meant to pay. But the only reason to do that is you want commercial support, from what I understand. There are no longer any special features. If you can support yourself (like most can) you just switch to OpenJDK as part of your Java 11 upgrade.
They have not changed the license for Java 8 users "on the fly", I'm not even sure that's legally possible.
The difference is that OpenJDK N will stop receiving security fixes the moment OpenJDK (N+1) is released. LTS releases are only LTS for Oracle JDK.
So no, OpenJDK by itself is not suitable for production use. To put a Java app in production securely you now need to either pay Oracle or find someone to provide security fixes to OpenJDK beyond what Oracle provides for free.
Security patches will be available for Java 11 via Red Hat, IBM and others (who have promised to do so). And the binaries will be built and made available here https://adoptopenjdk.net/ as well as via other OpenJDK build farms (eg. Azul Zulu).
Pardon me but AFAIK all JDKs are backwards-compatible. Unless you're doing some weird sh*t which exploits JRE bugs (oh, sorry.. features). But that just makes you a bad dev as you tie yourself to the implementation rather than specification.
The _unsafe_ part being removed is not bckw_compat, I give you that. But if you're tied to this hole you're doomed to become legacy code maintainer as it's not coming back.
Just upgrade to OpenJDK_v(N+1) whenever it's out. Get rid of Karaf, Liferay or whatever is holding you back. Don't become a legacy app developer.
Thanks for clarifying. I went back to the BCL and it is indeed correct that the commercial features are listed under the supplemental license terms. Excerpt:
THE LICENSE SET FORTH IN THIS SECTION 2 DOES NOT EXTEND TO THE COMMERCIAL FEATURES. YOUR RIGHTS AND OBLIGATIONS RELATED TO THE COMMERCIAL FEATURES ARE AS SET FORTH IN THE SUPPLEMENTAL TERMS ALONG WITH ADDITIONAL LICENSES FOR DEVELOPERS AND PUBLISHERS.
How is this possible? I have an app that runs in the JVM which is also bundled with a JRE in some platforms. Does this mean that I cannot freely distribute it anymore?
I notice that the OpenJDK build is only available as a .tar.gz and not as .rpm
This means that to upgrade from Oracle JDK10 -> Open JDK11, you'll have to write a script yourself to modify the symlinks e.g. to redirect the existing "/etc/alternatives/java -> /usr/java/jdk-10.0.x/bin/java" to the new installation. There are 46 of these symlinks that need changing (for javac, jstack, etc etc).
I hope that's the only change that is required and that I'm not missing something. Anyone know if there is anything else necessary?
Edit: here is the script I just wrote to print out the commands required to change the symlinks:
#!/bin/bash
existingJdkBinPath=$(dirname `readlink /etc/alternatives/java`)
newJdkPath="/opt/jdk-11"
find /etc/alternatives -type l | while read link; do
target=$(readlink "$link")
targetPath=$(dirname $target)
targetFile=$(basename $target)
if [[ $targetPath = $existingJdkBinPath ]]; then
newTarget="$newJdkPath/bin/$targetFile"
echo ln -snf "$newTarget" "$link"
fi
done
The OpenJDK build is GPL and should find its way into official package repositories. Oracle may have stopped creating the rpms for that reason.
Most distros use the IceTea builds for OpenJDK. Hmm . IceTea3 is Java8. There's no Java9 IceTea4 build yet. I can't find any roadmap info on their site ...
Remember, this is the same company that for years grossly knowingly overcharged the US government for licenses, resulting in hundreds of millions later paid in fines.
Their focus is pure bottom line. If that means cheating, so be it. If it means the equivalent of a bait and switch, sure why not.
It's really a shame that circumstances are what they are now. Sun may have had warts, but in comparison it was highly admirable.
As odd as it sounds given how things used to work, in the new model you are generally expected to go from 8 to 11. So you're not especially behind. That said, this transition will be rougher than most because of modules.
Yes, a collegue and I have both taken a look to the situation when version 9 was released and it's going to take some work to do the migration. But as it is I don't if we're going to 9 or directly to 11, but I think it's on the roadmap of the next version.
They switched to a different release model with major releases more often, but not all of those releases are LTS. Java 11 if the first LTS release since Java 8.
Red Hat and AdoptOpenJDK will be supporting OpenJDK 8 for quite some time yet. Oracle's JDK and JRE will stop getting public support, yes, but OpenJDK 8 will be alive and well for many years to come.
I was not referring to that. I was referring to the matter that they weren't ready to jump TO JDK 8 when JDK 7 was EOL, nor the next year, nor the next year after that.
What did they do with security updates when they were available for the version they were on?
Questions.
Don't get me wrong, they're not the only ones ice skating uphill on this.
Sometimes it's your clients that are painfully slow to update. I know a client that (a few years ago), after a lot of issues and wasted time, we discovered that they had a Sun JVM 1.5 with some bug on String.length ! And the worse thing is that they not like the idea of update to Java 1.7
The hell? You should just be able to take your code and compile and run it on Java 8. There aren't any major comparability breaks. Just try switching JVMs and run all your unit/integration tests (you do have tests right?)
Java 9 is the one that breaks nearly everything. We attempted Java 9 at our last shop and almost every dependency we used had some exception from a removed deprecated function down there in the stack.
We're already on java 8, the migration was done before I arrived, so I don't know how it went. But we've already taken a look at the java 9 migration and there's a lot of thing to fix. And we'll also have to remove the last java applets from the website...
Java8 changes the order hash maps return keys in. Those were never supposed to be stable, but because they were in practice, you're app may think they are.
It's really simple: Don't use Oracle's JDK 11 in production. Use one of the open source distributions. Commercial software really isn't that complicated.
>You may not: use the Programs for any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating your Application;
From what I understood, I as a student could still use java 11 from Oracle, as I wouldn't be using it for "production". Is that correct? Or are there other implications that I am missing here?
Yes, that is correct. This trap is for hobbyist and professional developers whose typical workflow involves downloading Oracle's JRE to deploy their app, probably not noticing the new trap clause deep within the license agreement.
My professional advice to a newcomer to the industry: stay away from Oracle. It is a blight on the software industry. Oracle is a monopolistic anti-consumer patent troll that treats its employees like shit and whose only business ethic is "make money by any means available".
Yea ... and if you do start to build something and decide to release it commercially, you don't want to run into any weird Oracle/OpenJDK weirdness at that point .. so best to start with OpenJDK.
Oracle seriously needs to be fought in court about this and their other actions.
They're actively hostile to the whole tech community and their entire business model is based on trapping people into paying for things by not making their licenses clear or changing their licenses.
I don't know why anyone would use any software made by Oracle these days, the alternatives and open implementations of their own systems tend to be faster - and their "unbreakable Linux kernel" is a joke and a legal disaster waiting to happen.
How is that? The license is pretty clear, as stated in the article:
> You may not: use the Programs for any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating your Application;
If you cannot understand that language you should not download or use the JDK.
They have been communicating the changes in how OpenJDK and Oracle JDK work for a year now, through many public talks, announcements, blog posts and so on.
Moreover the changes are good for the community. OpenJDK is now the reference implementation and equivalent to the old Oracle JDK in every way. The only reason to use the Oracle JDK now is to get commercial support from Oracle.
Calling this a "trap" is dumb. Not only did Oracle change the licenses to be better for end users, they are highlighting the changes in a big yellow box and the license is written clearly. OpenJDK is regular GPL + an exception so you don't have to GPL your own apps.
> Oracle seriously needs to be fought in court about this and their other actions.
The problem is, to win in court (not just go to court), you need actual grounds. What would be the grounds for suing Oracle in court?
For hiding the terms of the license? They didn't; the new terms have been as plain as any terms are in software licenses.
For changing the terms of the license? But Oracle was never obligated to supply new software on the old terms (unless the old license or some other contract obligated them to, but I don't think that's the case).
For changing the license terms on Java 8? But they had no obligation to continue to supply Java 8 under the old terms. (If you have an old copy of Java 8, the old license continues to apply, unless the old license specifies that Oracle gets to change it. Even if the old license does say that, it's not grounds for a lawsuit.)
So, specifically, on what grounds could you realistically sue Oracle?
Note well: I'm not an apologist for Oracle's behavior. I just don't think there's actual grounds for a lawsuit here.
> Oracle seriously needs to be fought in court about this and their other actions.
The problem is that very few companies have the desire or resources to do this. The community certainly doesn't have the resources. We'd need tens of millions of dollars of legal resources to fight their terrible behaviour.
I believe the article is mistaken. Their License says:
>"Program(s)" refers to Oracle software provided by Oracle pursuant to this Agreement and any updates, error corrections, and/or Program Documentation provided by Oracle.
- use the Programs for any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating your Application;"
To me this reads as, "you can use javac.exe and java.exe in development, but you can't use java.exe in production."
This is a huge change that I probably would not have noticed.
Well, if you ship Java software, it has to run on a JVM. You often ship the JVM you want with the software, or else help the customer get the JVM installed. If you install or help them install Oracle's JVM, you may still have a problem.
This sounds like total FUD. Sure the terms have changed but oracle has been open about it and told people to download openjdk. If you are going to run a commercial business and not pay any attention to the software you depend on and it’s licenses then you have another problem.
I'm not sure Java is worth the effort at this point. If I'm going to have to keep updating every 6 months, I would rather use Go, which seems to have all that Java has to offer + the backing of a huge corporation.
Right, what is the equivalent of the following in Go?
import org.apache.hadoop.*;
import org.rapidoid.net.Server;
In case you are wondering people not only using languages for language features but also for the quality/quantity of libraries available in those languages. This is why is very hard to bootstrap a new language. Java has a ton of great libraries that are essential to big data and high performance backend services that you do not have in Go. I could mention tooling as well but we can skip it for now, the aforementioned library situation is enough to not to consider go already. Btw. the new OpenJDK releases are just fine for running Java and many companies use it extensively already (like AWS EMR for example) to run production code.
Yeah, I don't doubt that there are many more Java libs. But for most uses cases today there are Golang libs as well. There's a Kafka client by Confluent, Elasticsearch client etc.
Actually I never used this argument for Perl. Perl was not really used for things like big data or high performance backend applications. You can use this reasoning for C++ or C# on the other hand and it stands. Many "big data" things re in C++ and a lot of high performance projects out there.
If you want to compare nifty scripting languages than you can compare Perl with Ruby or Python. In 2008 I was happily using Ruby for most of things we used to do in Perl, a bit slower yes, but who cared and it was much more readable.
How is that any different than updating a Go app? If a security issue arises in an older version of Go, it doesn’t magically fix in your app until you recompile it.
Java also has a multi decade history of remaining backwards compatible across major version upgrades. Barring known exceptions for things explicitly being removed, I don’t see that changing.
That Go may or may not be a trustworthy foundation to build on for the future you can't say it yet, but Google isn't very trustworthy on this front, while for Java oracle has been very boring but stable.
Having a self-contained single JAR that doesn't even depend on the host's ABI or OS and requires exactly one system dep - a JVM - is even nicer. And if you do want a statically linked self-contained ABI-OS specific binary Java give you that too now.
Personally, I wish Swift had a larger server-side ecosystem around it. I love the language, and some of the new web app frameworks (Vapor, Perfect, Kitura, etc.) are really great. However, there just aren't as many open-source, third-party libraries as there are for Java. To me, that's really Java's strength. There are libraries or clients for EVERYTHING.
I like Swift, too, and if it's a rap battle between Swift and Java, I think Swift has to emphasize C interop, and more recently (or perhaps "soonly"?) Python interop.
But regardless, we're gonna have to give it a few years to get a Swift ecosystem even trying to get on the mic in the same venues as Java/JDK.
I don't think this is gonna happen. There's no huge momentum behind Swift on the server. And when IBM is losing interest it will be reduced by 50 percent. Apple doesn't seem to be too much interested in Swift on a server (apart from releasing SwiftNIO, that's about it). When you take a look at the commit stats of Vapor on GitHub you will notice that there's not much going on either.
Java has 2 release cycles. A yearly release with all the latest and greatest available without waiting but whose support stops right after the next release is out. Java 9 went out of support when 10 was released and 10 went out of support when 11 was released.
Then there is still the regular one, release that get support for a very long time. That LTS releases and Java 11 is the first LTS release since Java 8. Java 8 will still be supported for a while even though Java 11 is out, giving you years to update.
So basically if you like how it worked before, in the days of Java 1.4, 5, 6, ... you just need to only look at LTS releases.
> I would rather use Go, which seems to have all that Java has to offer
Really ? What is the Go equivalent of J2EE ? Do Go appservers exist that offer all the features that something like Payara (Glassfish), JBoss or WebSphere does ?
What's the point of J2EE or an application server? You can get functionality such as templates, management, monitoring, persistence through other means as well.
Go templates come with the standard library, an ORM could be GORM, for monitoring you can get metrics of the runtime through the package of the same name also in the standard library or on an application level use the Prometheus client API to make your application talk to the Prometheus monitoring system.
I think the premise of JEE is that you label your class by @SessionBean annotation, and everything is installed automatically for that class: RPC, load balancing, security, monitoring, and you don't need to shop for individual components and find the way how to glue them together.
How this premise is implemented is another story. I am not sure about quality because didn't use jee for last 10 years, but when I was using it, IBM stack was far ahead of everything on the market, and was like your private PaaS with cloud functions, but with high license fees of course.
That sounds good. I wonder how it is implemented, though. I read through the WildFly feature list and there are several features you mention, such as clustering or failover. I wonder how you get to bridge the gap from the application to the underlying infrastructure, though.
I consider not having a suffocating bureaucratic "framework" that can be replaced by simpler and more straightforward constructs most of the time a feature and not a bug
But those that grow up under a bureaucracy tend to miss it
Yes, exactly. Having used Java and many other languages for years Java's strongest point is tooling - there are high quality tools for any aspect of software lifecycle. A lot of them available for free.
Of course new languages are quickly getting more and more tools but sometimes I feel that they are just reinventing the wheel (sometimes squared). For example: it's easy to host a mirror Maven repository, the file structure is very simple, even with per-project setting. It's not that straightforward with npm or cargo, they push you into centralized model with paid private repositories (npm).
> I consider not having a suffocating bureaucratic "framework" that can be replaced by simpler and more straightforward constructs most of the time a feature and not a bug
All those 'simpler and more straightforward' constructs cost a lot of extra time and effort, there's a lot of reinventing the wheel going on. Can you do something similar to just adding a field annotated with @PersistenceContext or @Resource and having a database connection injected ? Does it also allow for complete decoupling between the configuration of that datasource and the application itself ? Can it resize the database connection pools live, and then push that config change to an entire cluster, without writing a single line of extra code ?
You seem to confuse the language Java and the JVM. Updating the JVM (which you are not forced to do) does not mean that you need to update your code base. That's actually Java's main strength (and weakness), it is compatible all the way to version 1.0
In theory, the changes should really be minimal but to be sure we would need to have a very strong CI and stress testing platform to be sure about upgrading.
All good projects should have this in place anyways.
go ahead and try building a sufficiently large project written in java 6 on the java 9 jdk and tell me how backward compatible it is. Go ahead, I'll wait.
Back in college, I created a small desktop app that played a WAV file when any key was pressed, but could be closed silently with the mouse. (Its purpose, along with a recording of me screaming, was to train my cats not to sleep on my laptop.) It would have been written in Java 1.4 or maybe 1.3. The applet library was a pretty standard way to open and play an audio file, because it was simple.
Fast forward a few years, I came across the app again and decided to see if it still worked. It didn't work with the existing JRE on my box. So I rebuilt it with a more recent JDK (1.6, I think). It built, but it still didn't work.
See, Java 1.5 AKA "Java 2" had a new memory model, deprecated a lot of things (like applets), and started modernizing heavily. They attempted to maintain backward compatibility, giving us things like the awful erasure-based generics, but it really wasn't fully BC. They really should have just done what Python did with Python 3 and make Java 2.0 non-BC.
This isn't an isolated incident, either. A major project I worked on updated from Java 1.6 to 1.7 and it broke several things. They were fixed pretty quickly, but it still wasn't truly backwards compatible. It's just like the Java claim that you can write once and run anywhere, which is only half-jokingly referred to by devs as "write once, debug everywhere".
That's probably a misconception based on the new Oracle JDK release and support cycles; new release every 6 months, at which point support for the -1 version is immediately stopped (unless you have a commercial license or something). This LTS version is probably different (hence the name LTS), but it's also commercial.
Anyway it's a misconception because it only applies to the Oracle JDK, OpenJDK still follows a different support structure I believe.
Yeah. I'm kinda with you. You've got .NET Core and Go as reasonable contenders for new projects, but it's hard to justify moving an existing product away from Java. Not to mention, it seems that Java's still got a huge head-start on existing libraries vs Go / .NET.
Er... Well, I'm with you for a different reason than updating... I'm thinking that Oracle is just shifting the licensing ground too much for my comfort.
But why all the effort needed when you can simply use the open-source Java version called OpenJDK? It's virtually identical to Oracle's JDK, only without commercial support, and it's licensed the same way those other alternatives you're suggesting.
Besides, dotnet core would not be a better replacement: it's got a large corporation behind too, so nothing prevents them to do the same in the future.
As long as OpenJDK remains open and maintained for a reasonable length of time, I don't mind. Right now it's looking good, but only thanks to Red Hat (et al.) and not Oracle.
OpenJDK used to have some incompatibilities that tended to blow up in production (rare case "enjoyment") - is it now 100% compatible with original Oracle SDK? Otherwise companies would be forced to use commercial one in order not to disrupt their legacy systems.
Not 100%. There's still some weird edge cases having to do with the swing and crypto libraries. But the big performance regressions that we used to see are gone and with the release of flight recorder in Java 11, the last major commercial feature is now in openJDK.
In addition to compat, is performance on par too? I know the JVM is highly performant and was wondering if there were any patent restrictions that would prevent an open JRE (I assume there is such a thing) from being as performant as the Oracle JRE.
I've found that as of Java 8 the compatibility is pretty good, and I use OpenJDK exclusively now. Prior to that, it definitely had issues and I always used the Sun/Oracle JDK.
Agreed, it's what I've been using in production all along and maybe the rise of docker will mean that fewer people are directly installing the JDK on their production machines. Still, I bet there will still be some unfortunate souls that run the Oracle JDK in production without knowing the rules have changed.
As many have pointed out, you can argue if this is a trap or not and you can make the case for both sides. But I think that discussion in itself clearly begs the question: do you want to deal with a company that makes it easy to make a potentially immensely expensive mistake?
If anything, Oracle have demonstrated that if they feel you owe them something, they will take you to court.
I changed what primary programming language I use as a conscious decision that took years to make. First I had to find a language that was a good replacement and then I had to make the switch. Both require care.
It was easier than I had thought though. And I'm very happy I did.
Am I sure the my new primary language won't grow these problems? No. But I do know that I'd do it again if needed. There is no shortage of programming languages. There is a shortage of programming languages that have a sufficiently good ecosystem around them though.
(I mostly write server software, command line utilities and embedded software (embedded software in C/C++). If I wrote more embedded software on Cortex-M than server software om AMD64 I think I'd really like to use Rust.)
This is going to come off sounding a bit like victim blaming, but seriously, any business large or small must have a person or people whose responsibility it is to audit all installed software so that nobody gets into a situation such as described in the article.
A business cant afford to let devs just install software willy-nilly like.
It remains to be seen whether they'll "go after" the whales who can actually afford compliance staff (but screwed up anyway), or after the small-fish companies that just stood up a web-app to get started, or businesses in between.
It's not really the developers installing their own toolchain you have to worry about here, though. The folks working on the official builds and deployment should be far more aware of what's happening, because that's what has to be supported. If you're letting B&D do things willy-nilly, that's a serious business problem.
I aware they're often the same folks (DevOps), but your senior engineer and/or project manager should be watching what's going out.
What about compatibility? Recently I installed PDFsam on Windows 10 that required a JRE. I installed OpenJDK but the application didn't start. With Oracle JRE it did work. I didn't bother to debug the startup problems, though.
One would expect that the page provided by Oracle from which one could download OpenJDK would have the word "OpenJDK" in a header in 16+ point font-- and not visible only in link hover text box.
Question : this implies that Oracle 'knows' that you're using their JDL in production. Which implies a spy of some sort. Which is barely legal, is it ? unless it's at least duly stated in the licence.
Is it so ?
Azul sells their own high-performance Java runtime (Zing).
Taking a guess here, they probably realized there's demand among their customer base for plain OpenJDK builds with cheaper and/or more reasonable support offerings compared to Oracle's. And once you need to deliver those builds, it doesn't cost too much to let just anyone use them.
Zing and Zulu are not the same. Zing is a commercial JVM that has no open source equivalent, and has a completely bespoke design from my understanding -- calling Zing a "modified openjdk" is a stretch, from what I understand (especially considering OpenJDK is GPLv2.)
Zulu is Azul's build of open-source OpenJDK, and no different than any other OpenJDK such as one from jdk.net or AdoptOpenJDK -- it doesn't have a special JIT or special GC, but you can buy a support contract for Zulu (or use it at no cost). It's basically just another OpenJDK build, as far as most people are concerned.
I was talking about Zing, yes. The parent said Zulu and I din't want to go into details. And yeah... it is more than a modified openjdk, I think we can agree and say it is based on openjdk.
Really I think the best thing for Java at this point is getting it out of Oracle's greedy clutches. They are debasing the ecosystem of the language as a whole at this point.
I'd love to see the Java community fork OpenJDK and just leave Oracle behind. I wonder if the licensing of OpenJDK makes this possible? If so, the only (albiet huge) problem is getting a critical mass of support behind one particular effort.
You are right. I was just writing a flippant joke. The author of the post wrote a great article. I am also not insulting Larry Ellison. He (Larry E) is an interesting, very successful, guy. I am just saying he tends to win in competitions. Once you are locked in, you have to pay.
sorry, I was not clear. I am also not knocking owning an island. Thats a great situation to be in. If I am successful full enough in life, I will buy one! I am just saying don't mess with the dude. He tends to win.
Sorry, thats not what I meant. I was half joking/flippant. I meant to imply that Larry Ellison is very good at his job. His job is getting people locked into expensive proprietary languages (embrace and extend java) and DBs. Once your company thrives it becomes very difficult to get off their proprietary tools (which are excellent btw). Then you are forced to pay the man. I actually like the guy. His sailboat racing is really great tech.
> With JDK 11 Oracle has updated the license terms on which we offer the Oracle JDK. The new Oracle Technology Network License Agreement for Oracle Java SE is substantially different from the licenses under which previous versions of the JDK were offered. Please review the new terms carefully before downloading and using this product.
> Oracle also offers this software under the GPL License on jdk.java.net/11
https://www.oracle.com/technetwork/java/javase/downloads/jdk...
This information is either deliberately or accidentally missing in the post. If we assume the author did his research before writing this piece, I can only believe this was done with purpose.
They haven't been doing that with JDK licenses, so far -- as long as Java had licenses which didn't allow for this kind of gamesmanship. But now that the license has changed, it's a completely legitimate thing to get worried about.
If code was treated more like ideas or recipes we'd all still have jobs.
If you believe that strongly enough, civil disobedience through ignoring licenses is one approach. No one should risk more than they're willing to lose on the position because you will lose if it's costing someone else enough.
The Oracle license police live for situations like this.
p.s., If it's just personal use you are within the terms of the license.
The new license (https://www.oracle.com/technetwork/java/javase/terms/license...) is very clear. It states in plain English: "Further, You may not: use the Programs for any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating your Application;".
How is that not clear?
This entire article is just pure FUD. Oracle has stated over and over and over how the new licensing model works. It's clear to anybody who spends a couple of minutes reading the documentation.
You'd think it's clear, and yet I've joined projects where software with such terms was included in production builds because "it was downloaded with npm so it's open source."
Not saying anyone should stake any bets on that argument winning, just that it wouldn't likely be summarily dismissed in court and would at the very least factor into the damages calculation.
Will be interesting to see if any cases like this ever get adjudicated and precedent set.
Edit: Plus even if they aren't you still have the general mindset of "next next install close" where people are so normalized to getting something like that, to test or deploy it would be very easy to miss - given the license of the previous versions it would be an expectation that you would also be able to use the next version for commercial use also.
Although Oracle are perfectly within their rights to change the license, that doesn't mean it's not a dick move and a scummy thing to do.
There are certainly no default repositories that include this code. The whole point (and it's been this way for years) is that you can't download the Oracle jdk without clicking through a license.
In this process the person who downloads the new RPM (aka me) has to be 100% sure that the new JDK is ok to be used. Which I completely missed (my bad) I was wondering about the GPL stuff a bit but I was thinking that Oracle came to their senses and started to distribute the JRE/JDK under a license that is better than the previous one. Again, my bad that I paid attention more to the performance improvements, modules, ZGC etc. than to the license changes. This is why I was surprised when I saw the article from Joda (his real name is Stephen?) and also upvoted, sent around to all my Java peers to be aware that this is absolutely, 100%, pure fuckery that Orcle just dumped on us.
The download page [1] has a large bold warning that the license terms have changed. What else would you like them to do?
[1] - https://www.oracle.com/technetwork/java/javase/downloads/jdk...
I'm not sure you can blame Oracle for this. They could I guess give you a tl;dr summary in the box. But, how long would it take you to study the new situation? A few minutes?
It's debatable whether there are any true software engineers (we're certainly not licensed like traditional engineers), but all software professionals should be concerned about licenses. It's part of the job, as are all ethical considerations of your work.
For example, if agreeing to TOS was neccessary, Let's Encrypt could no longer be "totally automated". Therefore certbot has an "--agree-tos" option, present in oh so many ansible repositories.
If you haven't written a bot, but you habitually download the JRE/JDK from Oracle's website, accepting the license manually each time, is there really a difference? How many people are rereading the license each time they do this? I would guess the number of people that do this is roughly a rounding error above 0.
It's also social media.
Online surveys.
Everybody and your servers needs to keep mum about it or otherwise you'll get a call.
You think I'm making this up? I've worked at two places where we were in contact with Oracle police because they thought we used (more of) their software.
You ignore it, they move on to the next sucker. The people responding are the ones they'll work with.
In my book this is not a warning at all. This is clearly an attempt to mislead without breaking any laws.
What I've always done is install OpenJDK from the system's package manager :P
Just in case someone is interested in references Wikipedia has them near the text:
> OpenJDK is the official reference implementation of Java SE since version 7.
Source: https://en.wikipedia.org/wiki/OpenJDK
Even today on the Atlasian docs, they provide a Docker image of Confluence to evaluate, but if you buy a production license, you are required to build an OracleJRE Docker container (they provide instructions) for production.
It's been years and they still can't support OpenJDK ... it makes me wonder what weird proprietary crazy reflection shit they're doing in there.
It is a reason why we moved to .net core entirely. I have nothing running Java anymore. Shame as I liked Clojure somewhat.
https://openjfx.io/
[0] https://github.com/HotswapProjects/HotswapAgent/issues/218#i...
Why wouldn't it be integrated directly in the upstream OpenJDK source, though? It sounds like it would be a separate patched build that I'd have to download, and wouldn't be available if I just "apt-get install openjdk-11-jdk" in Debian?
So that means that even if you're running Java, you have three options: (1) Continue using it illegally, it will probably be a low risk. This is not advisable especially for larger corporates. (2) Purchase JDK license (3) Switch to OpenJDK
Java 8 has commercial features that are locked by default. You can unlock them by passing a command line flag that looks like -XX:+UnlockCommercialFeatures, so pretty hard to miss.
If you use those in production, you're meant to pay. But virtually nobody does use them. In fact Oracle open sourced them all for Java 11, perhaps because of that fact.
Now in Java 11 there are two JDKs, that are virtually identical. OpenJDK and Oracle JDK. The latter is the same as the former but commercially supported. If you use it in production at all, you're meant to pay. But the only reason to do that is you want commercial support, from what I understand. There are no longer any special features. If you can support yourself (like most can) you just switch to OpenJDK as part of your Java 11 upgrade.
They have not changed the license for Java 8 users "on the fly", I'm not even sure that's legally possible.
So no, OpenJDK by itself is not suitable for production use. To put a Java app in production securely you now need to either pay Oracle or find someone to provide security fixes to OpenJDK beyond what Oracle provides for free.
Just upgrade to OpenJDK_v(N+1) whenever it's out. Get rid of Karaf, Liferay or whatever is holding you back. Don't become a legacy app developer.
THE LICENSE SET FORTH IN THIS SECTION 2 DOES NOT EXTEND TO THE COMMERCIAL FEATURES. YOUR RIGHTS AND OBLIGATIONS RELATED TO THE COMMERCIAL FEATURES ARE AS SET FORTH IN THE SUPPLEMENTAL TERMS ALONG WITH ADDITIONAL LICENSES FOR DEVELOPERS AND PUBLISHERS.
This means that to upgrade from Oracle JDK10 -> Open JDK11, you'll have to write a script yourself to modify the symlinks e.g. to redirect the existing "/etc/alternatives/java -> /usr/java/jdk-10.0.x/bin/java" to the new installation. There are 46 of these symlinks that need changing (for javac, jstack, etc etc).
I hope that's the only change that is required and that I'm not missing something. Anyone know if there is anything else necessary?
Edit: here is the script I just wrote to print out the commands required to change the symlinks:
Most distros use the IceTea builds for OpenJDK. Hmm . IceTea3 is Java8. There's no Java9 IceTea4 build yet. I can't find any roadmap info on their site ...
Remember, this is the same company that for years grossly knowingly overcharged the US government for licenses, resulting in hundreds of millions later paid in fines.
Their focus is pure bottom line. If that means cheating, so be it. If it means the equivalent of a bait and switch, sure why not.
It's really a shame that circumstances are what they are now. Sun may have had warts, but in comparison it was highly admirable.
I could guess, because I've been at companies doing the same. Active development and support on the product, but no time for tech debt.
Java 9 and up I understand people getting frustrated with a more frequent LTS release and these weird microreleases every year.
What did they do with security updates when they were available for the version they were on?
Questions.
Don't get me wrong, they're not the only ones ice skating uphill on this.
Java 9 is the one that breaks nearly everything. We attempted Java 9 at our last shop and almost every dependency we used had some exception from a removed deprecated function down there in the stack.
From what I understood, I as a student could still use java 11 from Oracle, as I wouldn't be using it for "production". Is that correct? Or are there other implications that I am missing here?
My professional advice to a newcomer to the industry: stay away from Oracle. It is a blight on the software industry. Oracle is a monopolistic anti-consumer patent troll that treats its employees like shit and whose only business ethic is "make money by any means available".
Vendor lock in is a real bitch.
I'd go for OpenJDK simply to form good habits.
They're actively hostile to the whole tech community and their entire business model is based on trapping people into paying for things by not making their licenses clear or changing their licenses.
I don't know why anyone would use any software made by Oracle these days, the alternatives and open implementations of their own systems tend to be faster - and their "unbreakable Linux kernel" is a joke and a legal disaster waiting to happen.
How is that? The license is pretty clear, as stated in the article:
> You may not: use the Programs for any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating your Application;
If you cannot understand that language you should not download or use the JDK.
> or changing their licenses.
It was never clear they were going to change their license after years of making it $free to something not $free.
Moreover the changes are good for the community. OpenJDK is now the reference implementation and equivalent to the old Oracle JDK in every way. The only reason to use the Oracle JDK now is to get commercial support from Oracle.
Calling this a "trap" is dumb. Not only did Oracle change the licenses to be better for end users, they are highlighting the changes in a big yellow box and the license is written clearly. OpenJDK is regular GPL + an exception so you don't have to GPL your own apps.
To repeat, Java is getting more free not less.
(Actually, I'm sticking with JDK 8 for now.)
The problem is, to win in court (not just go to court), you need actual grounds. What would be the grounds for suing Oracle in court?
For hiding the terms of the license? They didn't; the new terms have been as plain as any terms are in software licenses.
For changing the terms of the license? But Oracle was never obligated to supply new software on the old terms (unless the old license or some other contract obligated them to, but I don't think that's the case).
For changing the license terms on Java 8? But they had no obligation to continue to supply Java 8 under the old terms. (If you have an old copy of Java 8, the old license continues to apply, unless the old license specifies that Oracle gets to change it. Even if the old license does say that, it's not grounds for a lawsuit.)
So, specifically, on what grounds could you realistically sue Oracle?
Note well: I'm not an apologist for Oracle's behavior. I just don't think there's actual grounds for a lawsuit here.
The problem is that very few companies have the desire or resources to do this. The community certainly doesn't have the resources. We'd need tens of millions of dollars of legal resources to fight their terrible behaviour.
Or any other major player in the Java space like IBM.
Customers' wallets will decide their faith
>"Program(s)" refers to Oracle software provided by Oracle pursuant to this Agreement and any updates, error corrections, and/or Program Documentation provided by Oracle.
Not programs you create using the JDK
- use the Programs for any data processing or any commercial, production, or internal business purposes other than developing, testing, prototyping, and demonstrating your Application;"
To me this reads as, "you can use javac.exe and java.exe in development, but you can't use java.exe in production."
This is a huge change that I probably would not have noticed.
Has Oracle been restructured recently, or are you expecting me to ignore the entire company's history?
import org.apache.hadoop.*;
import org.rapidoid.net.Server;
In case you are wondering people not only using languages for language features but also for the quality/quantity of libraries available in those languages. This is why is very hard to bootstrap a new language. Java has a ton of great libraries that are essential to big data and high performance backend services that you do not have in Go. I could mention tooling as well but we can skip it for now, the aforementioned library situation is enough to not to consider go already. Btw. the new OpenJDK releases are just fine for running Java and many companies use it extensively already (like AWS EMR for example) to run production code.
Java in 2018 is Perl in 2008, roughly.
If you want to compare nifty scripting languages than you can compare Perl with Ruby or Python. In 2008 I was happily using Ruby for most of things we used to do in Perl, a bit slower yes, but who cared and it was much more readable.
Perhaps even compare with Perl 6 :-)
Even Spark and/or Kafka.
Java also has a multi decade history of remaining backwards compatible across major version upgrades. Barring known exceptions for things explicitly being removed, I don’t see that changing.
And Google has a history of starting and scrapping products without much attention to the remaining userbase. I'm not saying Go is one of these.
But regardless, we're gonna have to give it a few years to get a Swift ecosystem even trying to get on the mic in the same venues as Java/JDK.
Then there is still the regular one, release that get support for a very long time. That LTS releases and Java 11 is the first LTS release since Java 8. Java 8 will still be supported for a while even though Java 11 is out, giving you years to update.
So basically if you like how it worked before, in the days of Java 1.4, 5, 6, ... you just need to only look at LTS releases.
Especially if you use Java for desktop applications rather than server-side. And Generics was not part of Go's plan for a long time.
I enjoy both but would not say Go offers all that Java has or vice versa
Really ? What is the Go equivalent of J2EE ? Do Go appservers exist that offer all the features that something like Payara (Glassfish), JBoss or WebSphere does ?
Kubernetes, Istio, Prometheus, All the Hashicorp stuff, hyperledger, traefik , kong you name it.
EDIT: I see from the docs http://docs.wildfly.org/14/High_Availability_Guide.html that you need to configure an Infinispan cluster, what looks like a non-trivial operation.
I consider not having a suffocating bureaucratic "framework" that can be replaced by simpler and more straightforward constructs most of the time a feature and not a bug
But those that grow up under a bureaucracy tend to miss it
Of course new languages are quickly getting more and more tools but sometimes I feel that they are just reinventing the wheel (sometimes squared). For example: it's easy to host a mirror Maven repository, the file structure is very simple, even with per-project setting. It's not that straightforward with npm or cargo, they push you into centralized model with paid private repositories (npm).
All those 'simpler and more straightforward' constructs cost a lot of extra time and effort, there's a lot of reinventing the wheel going on. Can you do something similar to just adding a field annotated with @PersistenceContext or @Resource and having a database connection injected ? Does it also allow for complete decoupling between the configuration of that datasource and the application itself ? Can it resize the database connection pools live, and then push that config change to an entire cluster, without writing a single line of extra code ?
無
In theory, the changes should really be minimal but to be sure we would need to have a very strong CI and stress testing platform to be sure about upgrading.
All good projects should have this in place anyways.
Back in college, I created a small desktop app that played a WAV file when any key was pressed, but could be closed silently with the mouse. (Its purpose, along with a recording of me screaming, was to train my cats not to sleep on my laptop.) It would have been written in Java 1.4 or maybe 1.3. The applet library was a pretty standard way to open and play an audio file, because it was simple.
Fast forward a few years, I came across the app again and decided to see if it still worked. It didn't work with the existing JRE on my box. So I rebuilt it with a more recent JDK (1.6, I think). It built, but it still didn't work.
See, Java 1.5 AKA "Java 2" had a new memory model, deprecated a lot of things (like applets), and started modernizing heavily. They attempted to maintain backward compatibility, giving us things like the awful erasure-based generics, but it really wasn't fully BC. They really should have just done what Python did with Python 3 and make Java 2.0 non-BC.
This isn't an isolated incident, either. A major project I worked on updated from Java 1.6 to 1.7 and it broke several things. They were fixed pretty quickly, but it still wasn't truly backwards compatible. It's just like the Java claim that you can write once and run anywhere, which is only half-jokingly referred to by devs as "write once, debug everywhere".
Anyway it's a misconception because it only applies to the Oracle JDK, OpenJDK still follows a different support structure I believe.
Er... Well, I'm with you for a different reason than updating... I'm thinking that Oracle is just shifting the licensing ground too much for my comfort.
Besides, dotnet core would not be a better replacement: it's got a large corporation behind too, so nothing prevents them to do the same in the future.
This is an LTS release. It will be available for more than a few months.
Poor little Oracle & IBM.
The 'default' JVM for Ubuntu is OpenJDK, right? You'd have to go out of your way to get your hands on Oracle JDK.
did google do that?
If anything, Oracle have demonstrated that if they feel you owe them something, they will take you to court.
I changed what primary programming language I use as a conscious decision that took years to make. First I had to find a language that was a good replacement and then I had to make the switch. Both require care.
It was easier than I had thought though. And I'm very happy I did.
Am I sure the my new primary language won't grow these problems? No. But I do know that I'd do it again if needed. There is no shortage of programming languages. There is a shortage of programming languages that have a sufficiently good ecosystem around them though.
(I mostly write server software, command line utilities and embedded software (embedded software in C/C++). If I wrote more embedded software on Cortex-M than server software om AMD64 I think I'd really like to use Rust.)
A business cant afford to let devs just install software willy-nilly like.
It remains to be seen whether they'll "go after" the whales who can actually afford compliance staff (but screwed up anyway), or after the small-fish companies that just stood up a web-app to get started, or businesses in between.
I aware they're often the same folks (DevOps), but your senior engineer and/or project manager should be watching what's going out.
http://jdk.java.net/11
But it is easy to get mixed up since it doesn't ACTUALLY say "OpenJDK" on that page.
It's just weird.
Taking a guess here, they probably realized there's demand among their customer base for plain OpenJDK builds with cheaper and/or more reasonable support offerings compared to Oracle's. And once you need to deliver those builds, it doesn't cost too much to let just anyone use them.
I guess they later figured it could be more generally useful and they could sell support for it.
From the article: They wanted to offer Java on the Microsoft Azure Cloud, unencumbered by complex licensing or end-user restrictions.
What are Oracle doing that their shiny enterprise offerings just have too much baggage attached even for Microsoft?
Zulu is Azul's build of open-source OpenJDK, and no different than any other OpenJDK such as one from jdk.net or AdoptOpenJDK -- it doesn't have a special JIT or special GC, but you can buy a support contract for Zulu (or use it at no cost). It's basically just another OpenJDK build, as far as most people are concerned.
And I wonder if it's inevitable. I wonder whether any language that successfully plays in that space will necessarily suffer the same fate.
The dude owns an island:
https://en.wikipedia.org/wiki/Lanai
https://www.bloomberg.com/news/features/2016-04-13/four-seas...
Stick with free/open source. Vendor lock in is a nightmare. edited for clarity.