The company I was working for at the time spent a not insignificant amount of money and effort migrating away from Oracle JDK when they first pulled this shit.
It was a B2B outfit, had maybe 30 customers running a dozen different products that the customers hosted themselves. The product was critical to business and the customers were large and part of critical infrastructure. Even a short outage would have made it into the news. What I'm saying is it wasn't a place where you could just hope for the best while migrating JVMs, everything needed to be tested and re-tested from every imaginable angle.
This was extremely expensive, but in the long run, it was still a lot cheaper than ponying up for oracle licensing costs.
I don't work there anymore, but I doubt they are repeating the process to migrate back, especially given how well OpenJDK works.
The license has a lot of nuances in it. OpenJDK is great and I honestly don't see a real reason to use the Oracle branded version for anything anymore.
I'm not sure about the current version, but Oracle jdk 8 had a few classes that weren't available in openjdk, we had to switch some cryptography calls to bouncycastle in our migration iirc
> The company I was working for at the time spent a not insignificant amount of money and effort migrating away from Oracle JDK when they first pulled this shit.
What did you migrate to? Another build of the OpenJDK? But it's the same code, isn't it? What's the difference that mattered to you?
Right but why? I'm not an expert in the difference but isn't it literally exactly the same code and functionality? What were you doing in that migration time?
There are packaging differences between various JVMs. Some of these are relatively minor (explicit or optional dependencies on X11 or other libraries), others are a bigger issue (how the Java keystore integrates with paths configured for system certificates).
in just a small project we ran into some odd differences in classpath/path resolution behavior. It wasn't a huge deal (and I'm not sure what we were doing before was "right") but there were definitely a few things we had to track down and fix, even in a "straightforward" project.
Why do you say it's exactly the same code ? Any Java developers can remember once in his life when openJDK didn't behave as the Oracle one, so you have to test. It's not the same binary, you remember times it behaved differently, and the client is important = you test once that it starts up at least, no ?
> Well what do you think the differences in the code are?
JDK-8210483 was a regression bug, you pass javac certain Java code which it handled fine in JDK 10 and earlier, in JDK 11 javac would crash with an assertion failure. Oracle fixed this in JDK 12 then backported it to JDK 11; the backport made it in to Oracle JDK 11.0.3, but missed AdoptOpenJDK 11.0.3 and wasn't in AdoptOpenJDK until 11.0.4.
I suppose this is a relatively rare scenario, but due to that bug we could not compile one of our internal apps with AdoptOpenJDK until 11.0.4 came out, whereas Oracle JDK 11.0.3 would compile it fine.
Even though that was a couple of years ago now, I'm still not going to assume that an Oracle JDK build and a third-party JDK build are going to have the exact same set of bugfixes, even if they have the same version number. This is why I think it is important to thoroughly test any migration between different vendor JDK builds before deploying it to production, even if in theory they are supposed to be identical. And even though that testing may be a relatively small amount of work for any given app/microservice/etc, multiply that across dozens or even hundreds of them and it all starts to add up.
> Why do you say it's exactly the same code ? Any Java developers can remember once in his life when openJDK didn't behave as the Oracle one, so you have to test.
In the past, definitely. But aren't all recent Oracle JDKs just OpenJDK builds?
There are some differences that each of the vendors adds in or removed. For example… Oracle Java does not include Shenandoah GC but all of the other distributions do. Azul Zulu Java 8 backported Java 11’s JFR while Oracle that code is behind the commercial flag.
> The company I was working for at the time spent a not insignificant amount of money and effort migrating away from Oracle JDK when they first pulled this shit.
Why such big cost? Changing JDK is just replacing some binary installed on server or at client.
that sounds negligible compared to the engineering investment that was preferred instead.
the logic of a commercially supported license is obviously the engineering depth of the original author's knowledge and in particular being able to refer to the authoritative / canonical answers
I don't have exact figures, but I'd guess our customers really weren't too enthusiastic about getting bullied into vendor lock-in with Oracle, which through this very act had already demonstrated their unreliability and willingness to renege on existing terms. That may have been the bigger reason for migrating. Staying on Oracle was definitely an option, but nobody wanted that.
negligible? It all depends on how much hardware you have. If you're a startup, you don't want scaling to cost you anymore than the hardware.
I remember reading years ago about the FB vs MySpace fight.
MySpace was (I think) .NET on Windows with SQL Server. Every extra machine cost a fortune in licensing. Whereas every FB machine was PHP/MySQL.
It matters.
It seems they were not in a dominant position in terms of market share. Anyone have a clue how low Oracle's market share was?
"Surveys suggest that Oracle's JDK distributions are not the most popular Java distributions anymore. Developers seem to prefer OpenJDK distributions from AdoptOpenJDK (now Eclipse Temurin), Amazon, Microsoft, Azul, and other vendors. These organizations also provide commercial support for their distributions. In the case of Eclipse Temurin, Azul offers such support."
And it wasn’t possible to perform unattended installations, because they required to approve the license manually (“y” from keyboard input), so Oracle JDK was excluded from any Ansible/Puppet/Docker deployment or Linux distribution. Immediate roadblock.
Wow, what a moronic decision by Oracle. Automating installations is so important, if you're deploying 1000 servers, to not be able to automate (even just for the one character button) is stupid.
The thing that killed most folks was the virtualized machines. They price on host, not guest OS. Got a 4 core virtual machine on a 128 core host... 128 cores need to be licensed. Those small web apps became crazy expensive where physical hardware is discouraged.
Not sure that would work in this case, `apt -y` would tell apt to skip confirmations, packages can still do their own confirmation. Also, NONINTERACTIVE=true (or what it is) I don't think would have worked either, as Oracle famously do their own thing.
Oracle JDK is pretty much the exact same as OpenJDK and Oracle commits 98%+ of all commits to the project. It’s hard to define a market when most of it is freely available.
Who does the work is immaterial to a lot of people. When Oracle bought Sun, literally everyone knew they'd move to a paid commercial license eventually. Which they did. I personally am amused at this sequence of events. It happened to other Sun products as well; open office, and mysql primarily. Commercial licensing didn't work for those open source projects either. What did Oracle actually gain from the Sun acquisition? With this news it seems like nothing. No tears shed for Larry.
Just to specific answer the question of what did Oracle gain, I believe they made back all of their investment across their Exadata line of products which were sold to large commercial enterprises, running on custom SPARC silicon.
Yeah, this. Larry bought SUN to complete his vertically-integrated stack: "You want Enterprisey Business App X? We sell you the whole server! No more worrying about hardware requirements, just roll this box in your datacentre and configure away; we guarantee it will work great." That, and ensuring their beloved Java stack (on which they had bet the farm) would survive. Everything else (MySQL, OpenOffice, VirtualBox, etc etc) was just bonus.
The acquisition made a lot of sense. I was a lowly minion in Oracle when talks between SUN and IBM fell apart, and I told everyone I met "it would be great if we bought them"... After the acquisition, I expected MySQL to die a horrible death and actually it kinda survived (although barely), which I thought was somewhat magnanimous. I was hoping they would just offload some of the stuff that simply didn't make sense (Oracle selling word-processors and chat clients, really...?), but sadly some busybody repackaged them into embarrassing products. And for years they went "business as usual" for Java, actually re-igniting development in a suspiciously proactive manner, which was great... until the day the license changed.
You sure about that SPARC bit? According to [0] v1 ran on HP commodity hardware, and the subsequent history repeatedly mentions intel xeon processors...
"it depends". The v2 box we had back in ~2009 was Intel and Linux on the compute side but SPARC and Solaris for the storage side. It had horrible throughput though for the 1st year or so that we owned it, but it eventually got better after some software upgrades. All the equipment was Sun branded though (except for the Infiniband switches, I think those were Mellanox, but it's been more than a decade so don't quote me)
Maybe they should've given out TCK licenses then? You know, the thing that exists to prevent fragmentation of Java except you're not actually allowed to use it?
TCK is free for OpenJDK forks, and I believe IBM has more than enough money to pay for it.
Also, java is one of the few languages with complete specifications, instead of saying that here is the reference implementation, what it does is the spec.
> TCK is free for OpenJDK forks, and I believe IBM has more than enough money to pay for it.
But it's not available at any price for independent implementations like Dalvik (I'm sure if it were merely a matter of money Google would've paid up). Most people who built the Java ecosystem were bait-and-switched: we were told the language would be free and the trademarks etc. were just to stop incompatible implementations, but that turned out to be false.
> Also, java is one of the few languages with complete specifications, instead of saying that here is the reference implementation, what it does is the spec.
Allegedly. Given that there are no independent published implementations (various organisations claim to have independent implementations but none of them are readily available), we should be sceptical in practice.
There aren't. There are OpenJDK forks and there are some mythical JVMs that pjmlp and like two other people have supposedly used but aren't actually available even if you are a billion-dollar hedge fund offering to pay the price that they're allegedly for sale at.
To be slightly less snarky there are also some pre-Oracle ones like JRockit; back in the Sun days the TCK licenses do seem to have actually been available.
You have an history defending Google's actions to screw the Java community in name of Android Java, so that is a natural thought.
And no, not an Oracle employee, but actually employed by one of the Java main contributors, quite easy to find out which one, although I speak in name of the Java community unable to write proper Java on Android, while ISO C and ISO C++ are fully supported.
Yes, and since code is copyrightable, and API is code, the default is that APIs are copyrightable. What was decided that this reuse by Google was fair use (which might give precedent to similar issues, but in itself doesn’t mean that APIs would not be copyrightable)
It’s more like nobody wants to do business with Oracle. The products themselves are fine. It’s the pray-we-don’t-alter-it-further licensing that’s a dealbreaker.
I beg to differ. The majority of their products are flawed and outdated. I'm not talking Oracle DB or Java but the vast amount of other apps they sell.
They bought lots of stuff, pull funding from development and redirect it to sales. Then they sell it to fit their vision; but nothing integrates cleanly and you'll be spending massive amounts of money on consultants who understand product A & B and how to connect them.
A java-dev can't do that; you need that A and B knowledge + integration skills. Those consultants are very hard to find and good effective ones nearly non-existent. The fees are enormous regardless of whether you use Oracle consultants, Oracle partners or freelancers. If you do manage to find cheaper consultants (offshoring most likely) be prepared for terrible quality as well.
Ow, and once you're finally comfortable with their stuff after spending all that money, be sure to make a reservation for the unexpected additional license fees they'll slap on you because you failed to remember the fine print.
> They bought lots of stuff, pull funding from development and redirect it to sales. Then they sell it to fit their vision; but nothing integrates cleanly and you'll be spending massive amounts of money on consultants who understand product A & B and how to connect them.
I had the "pleasure" of working with Oracle BPMS 10 at one point. It was a piece of crap they'd acquired (but apparently a better piece of crap that the other ones available at the time that the team had evaluated). It has pretty much zero code reuse features, and the consultants had taught the team to do stuff like cram all kinds of barely-related stuff into one "screen" so parts could be "reused." Getting support for all the bugs in 10 was extremely painful. It seemed like there was one guy who know what he was doing, and the rest just repeatedly asked for more logs. BPMS 11 was a rewrite with no migration path offered (but by the time that came around I'd noped out of that team).
The team eventually re-implemented everything in Activiti before support for BPMS 10 ended. BPMS 12 might have had a migration path (IIRC, a crappy one), but by then Oracle had burned their bridges.
I've never really considered Azul as I wasn't interested in the GC or JIT complier. Looks like their Zulu (non-prime) builds don't include them anyway.
OracleJDK got free for even commercial use for the latest LTS version with a “migration window” of 1 year after the next LTS version get released. So LTS to LTS jumping is perfectly fine.
For most companies, unless you haven’t switched already, I assume this won’t matter. Why switch back from Azul or whatever unless there’s a strong reason to? Nothing is preventing Oracle from trying to monetize their JDK aggressively again.
Oracle is in a nice position where they could discontinue or relicense OpenJDK, much in the way they did to OpenSolaris.
Let's be grateful they haven't done so yet. I'm not convinced there is sufficient talent to carry on OpenJDK without Oracle (contrary to the OpenSolaris→illumos situation).
i don't think that's consistent with history. there used to be a large number of Java implementations; by far the biggest reason why they (almost) all died out is because Sun agreed to open up their implementation. IBM still maintains J9, and while that's only part of a full Java implementation, I don't see any reason why Apache Harmony or GNU Classpath couldn't be revived and combined with it for a high-performance Oracle-less Java implementation. there is major precedent for this in the form of GNU/Linux, where substantial parts of the userspace are provided by GNU, but the kernel is a separate project.
Maybe - Red Hat have been doing more and more serious development lately, and (surprisingly) Microsoft are also stepping up to the table. I'm talking about whole new GCs, compiler changes, etc.
Plus there's GraalVM. Graal and OpenJDK are actually totally separate teams inside Oracle, who compete with each other! They have different licensing, versioning etc models too. And they've written an entire JIT compiler from scratch, which other firms are also developing expertise in (Twitter, Spotify). So even if OpenJDK changed a lot, that wouldn't necessarily imply Graal would change too.
Same with .NET. The stunt Microsoft pulled a week ago made me think that .NET needs a OpenJDK-like model ... until I realized that without the 200 devs from Microsoft no one will care enough to continue developing .NET.
In 2021, corporate Open Source is often just a response to the market pressure of genuine FOSS. If there's no community-based product, then users are always at the whim of the dominant company, and they can choose to leverage that dominance at any time.
Well that's what you hope would happen. Is there even still a big Java community? Android is by far the biggest community of users and they have moved on to Kotlin.
There is an enormous Java community, Java is the language of enterprise. But there are not many JVM developers, and most (all?) developers of the Java language work for Oracle.
The only natural candidates I can think of would be Google or Eclipse Foundation. I don’t see Google picking up development as very likely given their legal history with Oracle, and I think Eclipse Foundation would very quickly become stretched unless organisations like IBM are able to lend money and developers.
That being said, I think one of the more exciting futures for Java involves Eclipse taking a leading role in the development of the language and the reference JDK. I view them as the most important non-profit working in the Java ecosystem, and they are already stewards of Jakarta EE.
You’re confusing language with the compiled bytecode virtual machine that it runs on. OpenJDK underpins almost all of the VMs out there. Sure Android has it’s own JVM, but kotlin, scala, closure, jruby, jython, and more all still need to be compiled against a JVM and then run inside it.
I'm not confusing them. I am aware that all JVM languages depend on a JVM implementation to run. But the point is that if Oracle lock away OpenJDK then updates to the Java language are effectively closed source. That's a separate problem to supporting Kotlin etc.
To put it another way, I'm sure the Kotlin community is big enough to continue developing/maintaining their own JVM implementation (or just use the Android one). I don't think the Java community (that is, people who contribute to open source Java code; not just enterprises that use Java) is big enough to continue development of the Java language.
Do these enterprises employ robots? Do companies not open source internal projects? Do companies not hire people to work on open source projects?
The "community" is underpinned by corporations. If you look at the top trendy languages they're generally created or heavily supported by large corporations.
And also thank you, for giving many companies the necessary push for them to realize Oracle's JDK was not the only game in town and many others could deliver a perfectly fine JDK.
There are few things worse in this business than being labeled an "unreliable partner" and Oracle is being seen as just that even at big companies. Oracle's wisdom to pull this kind of bullshit is already legendary, the Open Solaris train-wreck, the MySQL writing on the wall, the OpenOffice implosion, the JDK shoot-in-foot, those samurais at Oracle's board sure know what they're doing..
Oh yeah I forgot Hudson, maybe that one wins 1st place as far as shamelessness is concerned, but because the fork was so swift and Jenkins took over very few people even remember Hudson.
Virtualbox was poisoned to take over the whole VM desktop "business" and then.. it stayed there. Not dead but not much vitality going on.
Oh gosh, I remember someone briefly mentioning Hudson in late 2015 (as a long-dead precursor to Jenkins) and that was the first I heard of it. I can't believe it was maintained until 2016.
> Oracle's JDK was not the only game in town and many others could deliver a perfectly fine JDK
Which are almost all just tiny changes on OpenJDK, developed almost solely by Oracle. So who actually deliver a perfectly fine JDK? Also, what do you even mean by JDK shoot-in-foot?
Well I'll break your anecdote. I "flocked" to Corretto for a production JVM-hosted system that ran on EC2 at the time that the Oracle distribution was re-licensed.
My reasons, aside from just licensing concerns? It came with a public long-term support commitment, and was deployed by AWS themselves on internal services before it was released publicly.
I remember the same argument of long-term support from the tech lead when he decided that the software we deliver to our clients would use the Correto JDK.
We moved to Corretto, and have been _very_ happy with them. For example, see how they handled an obscure "Swing seems to crash with my app, but not for anyone else" https://github.com/corretto/corretto-8/issues/331
Isn't it just the first choice in the list? IntelliJ offers several vendors (Amazon, Azul, Bellsoft, Eclipse, IBM, Oracle, SAP), defaulting to Oracle JDK 17. But I assume you need an older version for Android development.
I actually thought Oracle's move initially was actually a good thing: It brought some much-needed diversity to OpenJDK builds.
Very pleased to see this move as well. It's taken a very very long time, but it's encouraging to see Oracle finally understand the open source ecosystem.
Oracle commit 98%+ to the OpenJDK project, that they finished open sourcing and opening up paid only features year to year, to the point where OracleJDK and OpenJDK are pretty much identical.
Contrary to their litigious image, they are more than great stewards of the ecosystem and they do undertake open-source.
Indeed, specially because in spite of all the hate, no other company bothered to acquire Sun assets (with the exception of IBM that quickly withdrew their offer).
Without Oracle, there wouldn't exist Java 17, MaximeVM made into GraalVM, J/Rockit JIT cache as OpenJDK DSA, J/Rockit monitoring as Flight Recorder,....
And everyone could enjoy Java 6 with the JIT and GC improvements the FOSS community is known for, when there isn't some big corp sponsoring the work.
gcc is pretty advanced compiler and, AFAIK, it’s independent from big corporations. I wouldn’t deny the possibility for Java to live under truly open source umbrella.
looking at last 1000 commits to gcc, it seems like about 80-90% of emails are associated with "big corps". however, this doesn't tell the whole story. according to https://lwn.net/Articles/867540/, over 85% (100%-6.8%-5.0%-1.6%=86.6%) of Linux kernel changesets are supported by employers, but nobody sensible would claim that Linux is not community developed. whether it is because of historical project culture, or BDFL, or simply a large number of contributing organizations, there is clearly a substantial difference between Linux and OpenJDK development methodology.
The real challenge for Linux will be when Linus retires.
The Linux Foundation was intended act as the backstop here, but it is losing that focus, and I'm not confident that it will remain a trusted steward in the future.
For now, and to the point here, the sheer number of meaningful contributors to Linux is what differentiates it from things like Java and .NET. GCC is somewhere in the middle: less resilient than Linux, but more than Java.
Without Oracle it all could have just evaporated into public domain for other projects and interests to carry forwards. At least, that's what _should_ happen when any company folds, and when products are no longer supported by them. The entire set of copyright specifications, source code, everything should get added to the public stack of records.
I agree that the blossoming of additional JDK distributions, spurred on by Oracle's initial license change, was a good thing. I'm a happy AdoptOpenJDK / Temurin user, at work and at home.
However, I don't see any benefit to this latest change in their stance. Everyone already had to wade their way through the confusion from that initial licensing change, and many (most?) spent a lot of time and effort getting to a new stable configuration on a different distro. Why spend more effort, again, to run back to Oracle JDK? I think most organizations have better things to do than deal with all this.
Also, who's to say Oracle won't change their licensing deal once again for Java 21?
It also avoided licensing accidents. Oracles JDK always came with non free components and making the entire JDK non free made stories claiming that they "accidentally" triggered one of the commercial features and had to pay thousands in licensing fees unlikely.
I don't believe there are any commercial features left in Java 17. The last thing that required a flag to unlock commercial features was Java Flight Recorder, and that's now part of OpenJDK, the "-XX:+UnlockCommercialFeatures" is now gone completely from their documentation.
From the article -- Providing Oracle OpenJDK builds under the GPL was highly welcomed, but feedback from developers, academia, and enterprises was that they wanted the trusted, rock-solid Oracle JDK under an unambiguously free terms license, too. Oracle appreciates the feedback from the developer ecosystem and are pleased to announce that as of Java 17 we are delivering on exactly that request.
Translation, everyone stopped using our stuff in favor of the GPL version, that sucked so we changed the terms on ours to be free for commercial use. I bet they collect data and resell it but that is just a guess.
It's probably the same binaries, no added stuff. But yeah, it must have hurt them when the bean counters tallied it up :)
It's also probably worth financially supporting Oracle if you make substantial money from Java-based software. Oracle is by and large responsible for the platform that you are using.
> It's also probably worth financially supporting Oracle if you make substantial money from Java-based software. Oracle is by and large responsible for the platform that you are using.
Mmm... That's an interesting theory, but one does not really know if the money will be spent on tightening down the Java platform and legal attacks or technical improvements[1]. In practice it probably does not matter either way as that company is not cash-constrained in any shape or form.
Don’t forget that Oracle was guilty of shipping the AskBar as part of the JRE for the general public. That’s right, a malware which uploaded your browser history and redirected any 404 to a commercial advertising page, wrecking the web and the understanding of it for everyone.
Sun did it originally during the waning days as well as an even worse yahoo toolbar. Oracle discontinued the contract as soon as they could after acquiring Sun.
At the rate things are going, MySQL would also get this in the next 10yrs.
Oracle wants to extra as much resources as possible from any product. And when they realise the tech world has moved on, would try to throw a hinge to the wheel.
There are many other good JDKs out there, and with Oracle changing their license back and forth like a pendulum, I can not stress enough that going with the Oracle JDK should be considered a bad idea. See http://whichjdk.com/ for further detail (was posted here a couple of months ago)
This page was heavily criticized as it provides next to no reason on the recommendations.
Also, it’s really easy, just use OpenJDK (not adopt) packaged by your distro and stick to the latest version, which will continue to get security updates forever, will be much more performant, etc.
In the rare case you need to sit on an older version that is no longer getting security updates, OracleJDK may be preferred as they employ the actual people working on the JDK, and not just backporting commits from the most recent version. So eg. a deprecated feature may not get a security update in time with some other vendors, because it will not have commits from upstream.
> Also, it’s really easy, just use OpenJDK (not adopt) packaged by your distro and stick to the latest version, which will continue to get security updates forever, will be much more performant, etc.
* Updates for the life of the distro version support policy.
I seriously doubt it'd be any more performant. They're all just doing a build of JDK from the same central repo.
Oracle has been doing amazing work for OpenJDK and Java, it’s just that Oracle’s JDK isn’t a great business model. Glad that they realized that too and I hope it doesn’t stop them from putting resources behind it.
Maybe. Debian says[1] that their OpenJDK package will get "security updates on a best effort basis, but users should not expect to see updates for every quarterly upstream security update."
I'm not sure what that means, exactly. Will the Debian package have unpatched security vulnerabilities for several months at a time?
This applies to OpenJDK 17 in bullseye specifically, which is a special case because it wasn't released yet when bullseye was being released. There's the previous LTS version of OpenJDK (11) available in bullseye as well.
I think that means that the Debian maintainers appear to be understaffed and you should use the Correto or Zulu repository if you care about security updates.
Many systems either don't provide a modern JDK at all (for example macOS), or provide a pretty old JDK (for example I think Debian Stable only provides 11.)
The OpenJDK and OracleJDK are identical code bases since JDK 11 and are fully interchangeable. The only patches that exist for OracleJDK were the paid support patches for back ports.
If you stay on the latest JDK, then this was never relevant to you. If your company is not nimble enough to do that, then it could pay for the tired dinosaur patches and stay on old JDKs. Since other companies have started contributing to the effort of tired dinosaur patches again, it's no longer necessary for Oracle to charge a fee to produce them.
In other words, Oracle successfully averted a "tragedy of the commons" by asserting property rights long enough to make others behave and stop abusing the system.
They share 98% of the codebase. Oracle then sprinkles on top a small number of proprietary patches (some optimizations, a couple of tools) and their installer.
Depends on the version. Oracle has been working to shrink the difference with each version.
They include a bullet list in their release notes for the differences. At this point probably the biggest differences are that usage logging is only available with Oracle's build, and the Oracle build requires 3rd party crypto providers to be signed.
Other than that it's license difference, branding, and the installer does some things differently.
They are largely the same, OracleJDK building on OpenJDK. There used to be some paid only features like flight recorder, but all were open-sourced by oracle.
So as with most java vendors, you pay for the support.
I can’t find sources to support those claims. But AFAIK the main difference from practical POV is support time. Oracle OpenJDK builds are provided on rolling release cadence, there’s no LTS concept. Once Java 18 is out, you’re supposed to migrate ASAP. Oracle JDK does have LTS. You have a year after Java 21 LTS to migrate to it. But those 17.0.x patches will not be open source.
They probably can't. Every other business model they've tried hasn't worked. Their only other option is a buyout, and I can only assume Microsoft hasn't offered them enough money yet, because otherwise I assume that would have happened years ago.
No, you can also be profitable (or healthy) as-is and keep humming along.
In docker's case they are on the bankruptcy trajectory so now they have to make choices to change that trajectory (or select option 1 and go bankrupt).
It's missing: continue what we're doing since it working. My company already found a way to make money, we don't need to be bought and are far from bankrupcy.
That doesn't work for docker since they are on a decline and the business isn't sustainable as it is anymore. So they are on a bankruptcy trajectory already.
But what else is Docker to do? It feels like some companies should be bought out jointly by the tech giants and turned into charities since they have no business model but provide excellent value to the ecosystem that isn’t capturable.
Based on the Inside Java podcast, the reason was more along the line to ease installation in cloud environments. This new license is legally installable without clicking accept license, etc.
Also, making the last 1.5 (LTS+1 year into the next LTS) years free probably doesn’t mean a serious profit loss, as those primary come from things running Java 8 for another decade still.
SCO v IBM was settled back in August.[1] There might be some minor suits still ambling their way through the system but SCO is long bankrupt. I think it's safe to say that the company is down for the count.
That said, I'm truly curious who's going to buy and resurrect the SCO name next.
No, this article is about using Oracle's binary build for JDK 17, which Google does not use.
The Oracle v. Google suit was in the end about Google copying the Java APIs (via Apache Harmony). While the case was ongoing Google migrated to the OpenJDK, which Oracle provides under a GPL+Classpath exception. With the case now decided, as long as Google adheres to the license Oracle has provided to them there's no controversy left.
oracle could have not been morons and gotten the entire world stuck on java 11, but as we all know, oracle has one product, and it’s called vendor lock in.
> [For LTS Oracle JDK versions] security updates will be available for a total of three years. After that period, further use of the Oracle JDK in production requires a commercial license.
Apparently the business model is having commercial customers deploy Oracle JDK and suing them as soon as they forget to upgrade after three years.
I interpret this that if you want more then 3 years of security issues fixes you have to pay, it is similar on how other companies charge for extended support, if you don't like it you update faster.
But what is your opinion, everything should be free for big companies to use and then who pays the developers? Even in Linux world you need to pay to get extended LTS support.
I read it as after three years the Oracle JDK cannot be used any longer without a license, there is no option to continue using it in production without support.
Reminds me of the free for non commercial use VirtualBox plugin that makes itself super easy to install by random endusers, and then phones home so that enforcement on the sales side is almost automated.
You also can not distribute it for no fee, which impacts anyone that wants to, say, do a desktop app and ship a bundled executable, which is, arguably, a key tenet of the modularization effort done in JDK 9 to make the JRE lighter and more nimble.
That seems like a mistake, but it's very problematic if true. Having to go through a grueling JVM version update every 3 years, or more often if you can't jump 3 years worth of JVM updates at once? Brutal.
Since when is it grueling? 8->9 was slightly hard, but mostly due to old dependencies doing shit with sun.misc.*, they shouldn’t have and it took time to update them. But even a Java 1.1 class file will run just fine on Java 17, and with the strong encapsulation enabled in recent versions, no hard update will come again (as the internals are not reachable from code, they are free to change)
Right, the question is whether it's "after X time using it at all costs money", or "after X time updates cost money" - one of those is a lot easier to defend.
Yeah, right. As if I'm ever going to allow anything Java-related on anything I manage again.
"This application requires JRE #" -- end-user Googles JRE # and downloads/installs it.
End-user organization gets sued by Oracle lawyers for 10K site licenses for JRE #. Sure, they COULD have downloaded OpenFerretMongrelAsphalt JRE Pi, but yet, here we are...
Yep. It’s safest to classify using Oracle software as a business risk. After a due diligence evaluation it may be an acceptable risk, but you darned well better research it before assuming everything will be fine.
Isn't the recommended way of distributing Java applications nowadays to bundle a custom JRE with it? Wasn't project jigsaw especially created to be able to just bundle libraries and/or classes the application requires instead of the whole JRE?
Yes. The official stance of the OpenJDK organization is that there is no such thing as a "JRE" anymore, and applications are expected to use jlink or similar to bundle a customized Java runtime.
The distributions that matter here are for the JDK, which simply provides the "full" Java runtime along with developer tools such as javac and jlink.
Yup, you go and explain that to, say. Ubiquiti. Their network management software still requires end-users to download JRE v8 (and noothing else: it won't work). And, once end-users do that, they get sued by Oracle. But, serves them right, right?
VirtualBox is GPL2, but the 'extension pack' is under a personal use and evaluation license that doesn't cover commercial use. You're supposed to buy an Enterprise license for that.
The extension pack covers "Support for USB 2.0 and USB 3.0 devices, VirtualBox RDP, disk encryption, NVMe and PXE boot for Intel cards." according to the website.
My understanding of those (thus maybe wrong) is, that they are built on too of third party licensed code and patents. Thus opensourcing is hard and would require reimplementation. Thus choice is this model or nothing. One could also create those modules as open source versions, but there doesn't seem to be enough interest by independent folks ...
I don't care too much about it, but I wonder whether the open sourcing of it and the Enterprise license for commercial use requirement are really orthogonal.
Nothing is forcing Oracle to "routinely check log files for downloads of the VirtualBox Extension Pack from nonresidential IP addresses and contact unlicensed users to enforce compliance" (per https://en.wikipedia.org/wiki/VirtualBox#VirtualBox_Extensio...). They could easily just say "this software is free for commercial and non-commercial use."
It went from Java to OpenJDK, to Eclipse Temurin (formerly OpenJDK from Eclipse Adoptium) or something. If that doesn't seem like a big mess to use I don't know what to tell you
If you follow Java & ecosystem at least a bit you needed to read one or two blog posts from reputable community members to figure out what the situation is and what to use.
To compare I find a licensing situation on mid-size (50+ direct dependencies) or larger project much harder to comprehend - you need to figure out what licenses are used, if they can be used at all due to the requirements and company's policy, if they are compatible with each other and what's required for distribution.
It is confusing from the outside though, trying to decide if you should use Java from your distro, from Oracle, Azul, Amazon Corretto, AdoptOpenJDK, Eclipse Temurin, or Red Hat OpenJDK. Which ones have might have builds for your various platforms, what support they might offer, how closely they track OpenJDK, etc.
One good example is what is meant by "LTS". You get different answers to that question depending on which JDK it is.[1]
I don't remember another language where it was ever this confusing.
The JVM isn't a language. Kotlin, Scala, Clojure, and Java are languages. I'm quite pleased there are an abundance of options when picking a runtime. Yes, Oracle has not been a good steward, so having numerous open and free alternatives is a positive thing.
Oracle bas been and continue to be a good steward. Who finished the open-sourcing of OpenJDK to the point where it is feature-equivalent to their OracleJDK? Who pays for 98%+ of developers actually working on OpenJDK, on which other companies build their tiny modifications to create a “new” runtime? Who finances GraalVM and other top-notch research?
You can hate oracle all you want for some of their other segments, but they are insanely good at managing the Java ecosystem and we should be thankful for that.
This is a very valid counter-argument and perhaps I've been influenced by Oracle's general reputation, as well as not fully understanding who is responsible for the various open-source builds. I agree that the JVM is a fantastic platform and if it's Oracle putting in most of the work and the funding then I take my statement back.
That's true, but a little pedantic. If you look at it from the lens of "I've picked a language (java), now I need to build and run/deploy things", it's a confusing ecosystem. There's good arguments for why things are the way they are. But there's not really a good argument that it's straightforward and simple.
You are not making a coherent argument. Once you have decided you're building your server app in Java, it is MORE difficult to evaluate and decide Ubuntu, Debian, Red Hat, CentOS, etc. than it is to pick a runtime. Whether it has been like that "from day one" to use your term, is irrelevant. Secondly, having choice is GOOD. Yes it adds a bit of confusion but I'd rather have options than not. If you want some overriding authority to make all the decisions for you, go build on iOS.
Lol, you just can't leave this alone. Choosing a JVM is about 99% less confusing than the last 20 years of .NET Framework/Core/Mono mess and all its sub-projects (ASP.NET, Silverlight, WinFX, etc). At least in Java if you target v.11 you know to install JDK 11 (or higher). Meanwhile if you write C# v8 you need .NET Framework 4.8 to run it. Or maybe .NET Core 3 - which is now called .NET 5. Then over in Python land you've got IronPython, Jython, Pypy, plus the need to keep v2 as "python" on most Linux'es and "python3" for running/building new stuff. Don't forget virtual environments so you can pip install one version of a certain package while keeping it separate from a different installed version of that same package elsewhere. Java is super simple by comparison.
Just simply issue pkg-manager install openjdk and that’s it. Most vendors are just repackages of upstream, and you more than likely don’t need n years of support.
Most other languages don't offer long term support.
You can't run an old version of Python and continue to get security and performance backported fixes. Same thing with GO or Ruby or Swift.
I can't remember what Microsoft does for .Net, but I suspect you also need to always be on the newest CLR to get updates.
I think this is one of the major differences with the JVM, in a way, it has more options and vendors which should be a good thing, but it seems to mostly confuse people.
No, they're not. It's a silly idea with a pretty specific target audience. Most shops don't have time to waste on keeping their customers' JVM up to date by re-releasing their applications with new JVMs.
This feature is mostly useful when you want to ship a particularly stripped down version of the JVM for footprint reasons.
Oracle has proven themselves to be a litigious organization. You're not wrong that there are probably safe ways to interact with their organization's products but why bother when there are alternatives from companies that don't have such dirty legal histories?
The longstanding disaster of Java version numbering and licensing continues. How long until they reverse course on this? I don’t know of any other popular language with a such a sordid history in these areas.
Well lets see. It started off as JDK 1.0. The became J2SE 1.2. Then later Java SE 6. That took like a decade. Then they had sporadic releases for 5 years or so. Now they want a release every 6 months. Never mind the licensing/ownership issues over the years and now the proliferation of multiple distributions that are basically the same.
It was a B2B outfit, had maybe 30 customers running a dozen different products that the customers hosted themselves. The product was critical to business and the customers were large and part of critical infrastructure. Even a short outage would have made it into the news. What I'm saying is it wasn't a place where you could just hope for the best while migrating JVMs, everything needed to be tested and re-tested from every imaginable angle.
This was extremely expensive, but in the long run, it was still a lot cheaper than ponying up for oracle licensing costs.
I don't work there anymore, but I doubt they are repeating the process to migrate back, especially given how well OpenJDK works.