The OpenJDK is the source code. Like a master branch where commits are made.
That branch is always moving forward. New features added, new bug or security patched, etc.
Now there comes points where you need to package the OpenJDK source code into a binary.
This packaging process is done by multiple different "vendors".
Now Oracle packages for free a release every 6 months. That package is the Oracle OpenJDK. If another vendor did a package it would be Other Vendor OpenJDK.
Now the idea of back-porting is basically a cherry pick package. Instead of packaging the latest commit. You cherry pick only bug and security commits and apply them to say the release 8 commit. That way, you don't introduce new features, only bug fixes. Then you make sure you didn't break anything compatibility wise.
The idea is that those should be easier to migrate to, since by leaving out new features, you limit potential backward breaking changes.
This cherry picking merge, which can be painful to do, because sometimes you may need to address weird merge conflicts, or even make some changes to the fix since you're trying to apply it to a earlier commit then it was built on. This is what Oracle now charges money for.
Other vendors also offer back-ported releases for money. Azul and RedHat for example.
AdoptOpenJdk is a new community initiative trying to do backported releases for free with volunteer work.
And Amazon Coretto is doing it for free, but hoping that by moving to their JDK package, you'd eventually end up using AWS.
The amazon build of OpenJDK 11, Corretto [1], seems to be back porting some version 12 fixes as well. This could be the start of fragmenting the ecosystem all over again.
That seems unwarranted... they’re security / os syscall patches, and they don’t blur the lines between the JDK versions.
Even the article seems a little more FUDdy. As much as I dislike / don’t care for oracle, their JDK versioning approach reasonable. Commercial licensing for the special JDK, expensive support for the old versions, and open support for current openJDK version.
I don’t think even Go or Rails support major version minus 1 or 2.
> This could be the start of fragmenting the ecosystem all over again.
Absolutely not. The OpenJDK is the official reference implementation, and Oracle has open sourced everything important.
The only question is how quickly the various OpenJDK packagers will provide security updates. The Red Hat option looks very practical if you're a Red Hat user.
It's definitely has created distro hell. I feel like a huge reason Linux can't get more desktop share is because we don't combine our effort and a lot of duplicate work is done between the distros. It's inefficient. There are things like flatpak now though...
I think your comment has little to do with the fragmentation of the Linux kernel (which the GP was referring to), and more with the ecosystem around it.
Yes, it's fragmented, especially in the mobile and dev board spaces. That feels different than not knowing if two Java 11.1.2.3.4 builds are the same thing.
I just got some of our apps moved to corretto yesterday. Smooth so far on corretto 11, hopefully 8 goes the same way. I think Oracle really shot themselves in the foot with this model, they are going to lose control.
From an Amazon job posting. Seems to imply at least some of the Corretto maintenance would be in-house, at Amazon:
"sharing your findings with the rest of the engineering community, hardening your patches in Amazon's production systems, releasing them as part of Corretto, and contributing improvements back to OpenJDK."
I am deeply confused now by the name "openjdk." I thought openjdk was the open source version, but it seems like it's just an adjective according to this article.
IceTea is one OpenJDK JDK? Azul is another? Does IBM still maintain a JVM and will that be another? What the hell is this thing:
OpenJDK is the name of an open source implementation of Java. It started as an open sourcing of part of the codebase to Sun's JDK, and gradually more parts moved from the closed source portions to the open source ones (i.e. OpenJDK). Sometimes, some closed source, commercial features were added, but as of JDK 11, Oracle completed open sourcing the entire JDK -- that's OpenJDK.
IBM still have their own VM, J9, and while they produces JDK builds that they misleadingly call OpenJDK, they are not. They replace the OpenJDK JVM (HotSpot) with theirs, but keep the standard libraries. So it's not OpenJDK, but it's a JDK that uses most of the OpenJDK standard libraries.
Azul have two JDKs. They have the proprietary Zing, which uses their own VM (which, in turn, is a modification of HotSpot, which they licensed, with their own optimizing compiler and GC) and the OpenJDK libraries, and the open source Zulu, which is an OpenJDK build.
I think IcedTea is also an OpenJDK build.
> What the hell is this thing: https://hub.docker.com/_/openjdk Is that Oracle's OpenJDK release, which is different from Oracle Java? Or is this the IceTea release?
OpenJDK can be an upstream. You can build it as is or create your own derivative version. If someone creates a modified version they put their own name in front to clarify.
OpenJDK seems to effectively be a standard, or set of interfaces/classes that must be provided.
Oracle's OpenJDK build is very similar to Oracle Java but comes without the support contract or the license fee. Amazon are apparently working on one tailored more to AWS, etc.
(edit: didn't realise it was the literal upstream source - probably best to ignore my comment!)
I'm not in the Java world, but is it possible to make Oracle irrelevant? Are there not language specs, IDEs, and JVMs available from non-Oracle sources? And if not, why not?
You can just use the latest OpenJDK. That's the open source version. But the enterprises want to use the Oracle version. Which they can, but they would have to pay for it. So, I assume, most of the hullabaloo is about Oracle charging for their JVM.
Essentially, for whatever reason, there are people who don't like open source. So they don't want to use the open source JVM.
I work in an organization that has bought support for Java (11, I think). Your comment is technically correct, but doesn't capture the whole situation I believe.
We use OpenJDK11 currently. The reason we're buying support is because bug fixes and backports END for JDK11 once JDK12 is (already was) released. If you want security/bug fixes, you'll need to upgrade your application to the new JDK every 6 months. For a team like ours (~8) people, it's simply not viable for us to be in a state of continual upgrading. We wouldn't get anything else accomplished. Our job is to provide value to the business, not be stuck in perpetual runtime upgrades. Buying the license allows us time between upgrading JDK versions so that we can target jdk11 for new applications.
For quite some time after jdk11 was released there was also a prevalent opinion by some of the more senior members on the team that Oracle was going to be gimping the OpenJDK release in some way or another. Even after being shown that that wasn't the case we had _multiple_ meetings where it was discussed that we shouldn't migrate to OpenJDK because of bugs that "existed in there, that don't in Oracle build". This is most certainly due to historical reasons, and I don't blame them for thinking it.
I can't speak to why we don't rely on other LTS options, I was not a part of the meetings that decided our actions. Ideally, we would rely on something like adoptopenjdk, but the powers that be decided to pay Oracle instead.
> If you want security/bug fixes, you'll need to upgrade your application to the new JDK every 6 months. For a team like ours (~8) people, it's simply not viable for us to be in a state of continual upgrading.
You need to upgrade to a new JDK every couple of months if you want to stay secure even if you stay on LTS. You are simply assuming that upgrading to patches is easier than upgrading to feature releases. I don't believe this is true, certainly not over a long duration.
The new feature releases are time-based and were originally meant to be called 18.3, 18.9, 19.3 etc. Don't be confused by the fact that eventually people preferred the Chrome-like version naming scheme to mean that the new feature releases are major ones; they are not. In fact, the probability that your application would break by a patch release and by a feature release is not all that different.
We want the feature release process to be gradual and cheapest overall. The LTS path is meant for those who for some reason need a less gradual process than either the feature releases or the old model.
Of course, as an Oracle employee, I value your business, and I hope you choose to buy our support (that includes more than patches) even if you switch to the gradual update process.
Ideally if I had any say in the matter, I'd also choose to continue the upgrades. I'm unfortunately not in a position to be able to make decisions for the company, or even team really.
The culture for us leads to more problems imo. Tests aren't required. We have > 100 legacy applications (most C#, but some java). I'm currently working on porting a webapp developed 5 years ago, written on jdk6 (I think) using Hibernate 4.x.y, to java 11. There's no tests for the webapp. The majority of the code was written by contractors. I've removed hundreds (if not 1-2 thousand) of lines of commented out or dead code before I even started refactoring. In this case, which I agree is probably an outlier, updating takes too long. Or maybe I'm too inexperienced.
In my managers eyes, they see how long it's taking to migrate to JDK 11, and they don't want that for every new "major release" (12, 13, etc)
> In my managers eyes, they see how long it's taking to migrate to JDK 11, and they don't want that for every new "major release"
How long to manage from what version? There was one huge major version between 8 and 11 -- 9, the last one ever. So if you go from 8 to 11, then you're basically doing one major release, plus two feature ones.
> Tests aren't required.
That's unfortunate, because even patch releases can break your application (and possibly at a probability that's not significantly lower than that for a feature release, although they are both low). In fact, this happened in 11.0.2/8u201[1], which was possibly more disruptive than any of the recent feature releases. Both feature and patch releases require the same amount of testing on update. If someone thinks they don't, then they are very deeply misguided.
Getting support is good, but having an understanding of the platform is also good. Having good tests is probably better than both :)
So I have been in Java versioning hell before, and I empathize--but that was, like, Java 5 to 6. My experiences with Java since then have been almost completely seamless. So, this may be a silly question, but I'd be curious: what is so disruptive to your workflow that upgrading a JDK, running your test suite under instrumentation to smoke out incompatibilities and noticeable perf/memory/etc. regressions, and deploying it would cause you to not "get anything else accomplished"?
I can't speak for the OP, but from what I've seen in other organizations a reluctance to upgrade JDK versions usually indicates a lack of confidence in their test automation suite. If they can't be confident that their tests will catch regression defects then a JDK upgrade seems risky and requires planning ahead for a major manual testing effort. This is just one area where getting to 100% automated functional testing delivers huge benefits.
Pretty much right on the nose. As I mentioned elsewhere, testing is not required where I work. As such, there's no guarantee that upgrades to JDK won't break something behind the scenes now only to blow up later in production.
Most test suites cannot test long-term stability. We once had a commercial J2EE app that would run fine for weeks on JDK 7.x but commit continual-GC suicide or burn 100% of all cores after about 24 hours on JDK 7.x+1.
After this happened with multiple oracle “bug fix” releases, we of course stopped upgrading as much as possible, spending days trying to determine if each security hole being patched in the JDK was actually an attack vector for this app.
We also implemented periodic “therapeutic restarts” on all app servers.
It was like running a critical server app on Windows 95.
Major java versions have been known to have different default settings/properties from previous versions, without any mention whatsoever in the release notes.
Any 'minor' change in a user application, font being a common example, can have a significant negative impact for an enterprise that has built workflows around that application.
That assumes we have (any) tests, or benchmarks to refer to. Plus, we have a decent amount of legacy java apps (java 6 - 7) and we'd be going straight to 11. On the project I'm on now, it's not a smooth transition.
Care to post what stack you’re on? We’re on Gradle and SpringBoot and JDK upgrades have been zero changes for us so far (other than changing the version number of course). The backwards compatibility has been superb - what breaks for you?
Not the OP, and our stacks/reasons are probably different, but for perspective, I work on a large Canadian Federal Government project, and a minor change in Java version on severs for our legacy application, is probably... 1-2 months elapsed time, minimum. And that's if we get the change approved.
Mostly it's the slow and manual change management practices, slow and manual approval framework, slow and manual testing approach, slow and manual implementation procedures, and other things that are slow and manual.
Enterprises would have to pay only if they want to buy support from Oracle. Oracle provides the JDK, without support, 100% free, for any use: http://jdk.java.net/
Well, yeah. I was just assuming that the enterprises must want support? Because why else would they be so up in arms? As you correctly pointed out, they can download and use Oracle's JDK for free. So if they don't want support, then I really have no idea at all why they are raising such a stink?
One of my previous employers, which happens to be exceedingly risk averse, switched to OpenJDK (and away from Oracle) for just this reason. Generally speaking, if someone is sufficiently paranoid, it doesn't matter which JVM they are using as their systems will be secured in other ways.
You are. The community asked for those changes, but some don't understand them and are confused because they apply old terms to new concepts.
First, Oracle has completely open sourced the JDK, for the first time ever. Instead of a JDK with a complex license, mixing both free and commercial features and containing field-of-use restrictions, Oracle now provides the JDK under a 100% free and open source license, or under a commercial license for those who wish to purchase a support subscription (and fund the development of OpenJDK).
Second, there are no longer major releases, and the new feature releases are similar to the old six-monthly "limited update". JDK 10, 11 and 12 are roughly the same size as 7u2 and 7u4, which also didn't get free security patches after six months. What's changed is the name given to those releases, and to make the updates cheaper and easier, they have been made more gradual, by allowing spec changes in feature releases. Not only do you get security fixes for free forever, but there are no more major upgrades.
So the main point of confusion is that some confuse the new feature releases with the old major releases, when, in fact, they are much closer to the old "limited update" releases. People see a new version number, see that that number is not freely supported beyond six months and panic, when, in fact, the old releases that were similar to the new feature releases were also not supported beyond six months. They themselves were considered "updates" to some major release, but major releases no longer exist, and the "updates" now get a new version number. See here [1] for a more complete explanation.
In addition, there's another new model, that allows organizations that for some reason need a much less gradual upgrade process than the new one -- and even less gradual than the old one -- and that is something that Oracle charges for. But because the JDK is now completely open source, other OpenJDK members have committed to backporting the fixes to provided a similar step-wise upgrade path for free.
(I work on OpenJDK at Oracle, but speak only for myself)
I think the changes are reasonable, but the lack of historic support and the timeline of the changes are not.
Java is deeply engrained in much of enterprise software, which is slow and difficult to change. The licensing change was not given with nearly enough heads up for companies to properly assess their options and migrate to OpenJDK if they choose. From a user perspective, where it’s known that switching JDKs and updating major versions is often not a straightforward task, it sure does seem like this was carefully planned to make it too difficult to move off the JDK that just got a lot more expensive to use.
My company is dropping Oracle JDK entirely and moving to Open JDK, and over time transitioning off of java wherever possible directly due of this change. We are not a small company. It took several months just to figure out the scope of how widely the JDK was in use, we had to cut Oracle a hell of a cheque to avoid licensing issues, and we aren’t doing it again. We have a dedicated team assembled to move off of Oracle JDK now.
The general consensus of the Java leaders in our company is that this is a last ditch effort money grab by Oracle to leech money from Java, which was feared from the day that Sun was acquired.
> The licensing change was not given with nearly enough heads up for companies to properly assess their options and migrate to OpenJDK if they choose.
I don't know what enough would be. This has been discussed and explained for at least a year.
> it sure does seem like this was carefully planned to make it too difficult to move off the JDK that just got a lot more expensive to use.
What? The change was that as of JDK 11, Oracle JDK and OpenJDK are the same software[1]. The same software that used to contain both free and commercial features, and that had field of use restriction is now 100% free and 100% open. If this is making it harder, I don't know what making it easier would be. If free is more expensive, I don't know what less expensive is.
> My company is dropping Oracle JDK entirely and moving to Open JDK, and over time transitioning off of java wherever possible directly due of this change.
Good, because that's what Oracle has been asking you to do[2]. Oracle JDK is now the name given to the same software sold with a commercial support subscription. If you don't want to buy support, don't use the package that includes it.
> The general consensus of the Java leaders in our company is that this is a last ditch effort money grab by Oracle to leech money from Java, which was feared from the day that Sun was acquired.
I am a bit concerned that the Java leaders in your company think that a money grab is taking a commerical offering and making it free. Oracle has now made the JDK 100% open source and free for the first time ever. To fund its development, it is also selling support for those who want it.
you will have to forgive thanatos_dem, they most likely work somewhere similar to my last job..gigantic org..you can tell them 100 times the asteroid is coming, but they ignore it until almost impact. They also have a very entitled idea of software, where in my situation we used tons of IBM software for years and were pissed off when IBM came looking for their money.. WHO WOULD HAVE THOUGHT? our leaders even so called them thieves (funny since we were essentially stealing their software for years knowing full well it costs $$). Years later? nope not migrated away from the IBM stuff, who knew it takes tons of work when you ingrain in any tech for that long, and ya. a staff that needs training on the new direction etc etc.
I say good for oracle looking to want compensation for support. And thanks to oracle for keeping it open source.. and well..your comments on the matter actually feel clearer than some of the information put out by oracle themselves hehe..
> Java is deeply engrained in much of enterprise software, which is slow and difficult to change.
Indeed.
I work on enterprise software, and we have to provide Java components for companies that require it. None of our customers want or can use anything past Java 8, and we have no plans on supporting anything past Java 8 until someone squeals.
Which is a bummer because JDK 9 added some nice convenience functions to the standard library. Like "transferTo" to avoid using like 6 utility functions just to move bytes around. It's stuff like this that will compile on JDK9 but won't run on JDK8 because the stdlib method isn't there that you kind of have to watch out for when deploying stuff on a machine that might be running an old JDK. But in general my engineering philosophy is it's usually worth it to keep things up to date, even if it's just because it makes the engineers happier.
InputStream in = Main.class.getClassLoader().getResourceAsStream(filename);
try {
OutputStream out = new FileOutputStream(file);
in.transferTo(out); // new in jdk 9!
out.close();
} finally {
in.close();
}
I understand your point. But realistically, if none of our customers want or can use anything beyond 8, the safest thing for us to to is to avoid upgrading our dev environment beyond 8. That way, nobody could accidentally use incompatible features.
Personally, though, I really dislike Java regardless of the version being used. I'm hoping that some day I'll be able to foist this aspect of my job off on someone else -- then I won't have to worry about it!
Just one data point: our IT has now blocked the whole java.com domain. Oracle Java is now primarily seen as an infection you get through the Java Updater. Yes, I know of OpenJDK and I'm currently in the process of migrating machines to it, but I can assure you the damage to Java is very real.
OpenJDK is the name of the JDK developed primarily by Oracle.
java.com is the website for "consumer-side" Java -- i.e. the desktop JRE. The JRE and "consumer Java" no longer exist (as they've been replaced by jlink), and so the website is out of date and largely irrelevant. I hope someone soon figures out what other use to put it to.
You might not like it, but java.com/download is still the first result when searching for Java.
I am aware what OpenJDK is and who develops it, and I can handle the changes to our systems just fine, but I'm an engineer, not a manager. I can assure you that the confusion around Java is very real, as well as IT departments worrying about machines updating to a Java version requiring a commercial license.
I don't think that the desktop JRE's autoupdater can automatically update to versions (of the old JDK 8) that now require a commercial license, but I'm not sure. I'll ask. But I understand and agree that communication/websites can and should be clearer/easier to find.
EDIT:
I asked about the JRE autoupdater, and got this answer:
Before update, it will offer to change the license to personal use (or to get a commercial one) or remove the software. It will default to remove. You can also choose not to upgrade and not to remove and keep using an out-of-date version. And if you accidentally remove, you can still get the old free versions from the Java archives.
This is the core piece of crucial information in all this, and I haven't found it anywhere else.
We have Java installed. As far as I know, we never told the installer if our use was planned to be commercial or personal. But in a few days, personal-use-installations will get a free update and commercial-use-installations will...
A) not get updates, through the updater using heuristics and mind-reading to divine that the installation is not personal?
B) get the update and thus be expensively out of compliance with the license?
C) have the updater present the problem to the end user and expect them to carefully consider the legal situation?
I think many people have assumed that the answer is B and are currently busy uninstalling Java everywhere, but if I understand you right the answer is actually C?
Is there more information on this anywhere? Most importantly, what is the correct official way to tell the updater ahead of time to keep the old version and never update? (We have a legacy application that uses applets.)
The answer is C.
I got prompted with a Java update and just went ahead with it, without much consideration; I mean, it's just a Java update, I don't even use Java for anything on this machine but w/e. This morning I got a panicked email from our IT, sent to a significant portion of the company about the fact that we now run a commercially-licensed version.
There is no longer a parasitic Java installation on my computer.
> I asked about the JRE autoupdater, and got this answer:
Thank you for asking! It all depends on the warning that is displayed, of course. I still think that our IT has a good point in blocking the update completely.
Dude java.com has been irrelevant for as long as Java Applets have been on the way out - approximately 15 years.
There are reasons not to use Java (such as it being legacy tech and the PITA that is using Spring and Maven when those are supposed to make life easier), but historic Java Applet vulnerabilities aren't one of them.
Dude, this is not about applets. This is about the Java Updater possibly updating to a version requiring a commercial license. It may be that the updater does not do this by default, but I've not yet seen any official statement about this.
One of the primary drivers for JDK support is security. As far as I can tell, Oracle remains the only member of the OpenJDK community participating in the vulnerability pre-disclosure process. They are also not releasing source for JDKs after 6 months. Therefore, users of non-Oracle supported JDKs will be exposed to a zero day attack between the time of Oracle's CVE disclosure/patch release and the time that their OpenJDK distribution creates, tests, and releases a patch. I would love to see these communities thrive, but the reality is that Oracle is strangling them in the crib by taking control of the most important support functions.
> Oracle remains the only member of the OpenJDK community participating in the vulnerability pre-disclosure process.
I don't know if that's true. I know the vulnerability group [1] has members outside Oracle [2], but I know next to nothing about that process. I'm told that nobody gets any advantage on security issues.
> They are also not releasing source for JDKs after 6 months.
What do you mean "after 6 months"? There are no longer major versions. Comparing the update schedule for 7 (a major release) and for 11 (a feature release) makes no sense. JDK 11 is more similar to 7u2 or 7u4, which also got security patches for only six months.
All fixes go into the OpenJDK mainline. What Oracle engineers won't be doing much of is backporting the fixes to old versions, which, again, aren't major versions. They won't be backporting much to 8 (which is a major release) now that it's five-years-old, either, but that's the same as under the old model.
> Therefore, users of non-Oracle supported JDKs will be exposed to a zero day attack between the time of Oracle's CVE disclosure/patch release and the time that their OpenJDK distribution creates, tests, and releases a patch. I would love to see these communities thrive, but the reality is that Oracle is strangling them in the crib by taking control of the most important support functions.
You're talking about users who choose one of the two new release models, and pick the one that's been designed as a paid service. If you're concerned about that, you can pick the other new model, which is not only free but easier overall.
Question about this then: one of the assertions I got from the article is that it is no longer permitted to run a server process with Oracle's OpenJDK build without paying for a license. In your opinion (recognizing that you don't speak for Oracle) is this correct?
Absolutely not. All OpenJDK builds, packaged by Oracle or anyone else, are released under the same open source license, that of OpenJDK itself. It has no term limits and no field-of-use restrictions.
So, as you understand it, a business that runs Jenkins on an OpenJDK build without a commercial (paid) license from Oracle isn't breaking any license terms?
The message from the Java updater applet wasn't exactly clear about this. I hate being cynical, but I feel like that was probably by design. I was under the impression that any commercial use of Java, JDK, or JRE required a paid license.
Oh, wait. The Java updater does not install an OpenJDK build. Why are you using the Java updater to deploy server applications? Oracle's free OpenJDK builds are here: http://jdk.java.net/
Anyway, the fact that you're using the updater means you're on Java 8. The five-year-old JDK 8 is past its free updates for commercial use. If you must keep using 8 (and continue getting updates) for commercial uses, you must either: buy support from Oracle (same as before for JDK 7 past its end of free updates), buy support from someone else, get OpenJDK builds from other organizations (like AdoptOpenJDK), or continue using an out-of-date version.
This has always been the case with old JDKs, except now you have a few more options than before. The best option is, of course, to upgrade to the current JDK (12), and keep getting free updates forever.
The recommended deployment model for Java now is to bundle the runtime with the application. The "desktop/consumer" JRE is gone in newer versions. Ask whoever it is that produces the Java software you're using to bundle the runtime with it. People who don't develop Java shouldn't concern themselves with Java runtime installations and licenses.
> Oracle now provides the JDK under a 100% free and open source license
Such altruism; Can they do this for the TCK? Why not? Maybe all of Graal then? That seems to be where many of the dev efforts went after some staff for those now-free, previously-closed components were either repurposed or let go. I don't mind a company trying to make money (granted, not a fan of doing it on the language itself), but we shouldn't pretend they are selfless by treating actions that other languages had long since done as special.
You think that large open source projects developed by hundreds of full-time engineers are meant to be altruistic? Spending ~$100M a year (that's my estimate; I don't have numbers) is not meant as a charitable contribution, and if it were, I'd rather companies contribute this kind of money to worthier causes than software.
> Can they do this for the TCK?
The TCK is provided free of charge to people who produce OpenJDK builds. It is not provided free of charge to people who produce non-OpenJDK JDKs.
> Why not?
Perhaps because this is still seen as another channel to fund all those hundreds of full-time developers who make this open source software. All open source projects of this magnitude -- Chrome, .NET, Android, Swift -- are also funded by various income channels. I don't think any one of those, including OpenJDK, is open for selfless purposes. That's just not how "Big Open Source" generally works. But it is a fact that Oracle open sourced the entire JDK, and many people think that's a very good thing.
There are differences which are worth noting. Any system shouldn't be considered open if test cases are held in secret (even if they are just implementation test cases). Opening the entire language and runtime is considered the norm these days, not especially laudable.
First, I didn't say it was laudable, just that it's a fact. Second, is it the norm? Neither Cocoa nor .NET are fully open source AFAIK. Finally, the TCK tests aren't held in secret; they are licensed for free, but are just not open source (yet?). There are plenty of tests in OpenJDK, though: http://hg.openjdk.java.net/jdk/jdk/file/805584336738/test
The goal might be forced evolution. A few years ago no startups wanted to touch Java, and the ecosystem was lagging. The rapid release cycle is bringing much needed improvements
As I understand it, Jython was not affected by Python Global Interpreter Lock (GIL), is the same true for GraalVM Python? If it is than it would be a great way to to speed up python applications.
wow thanks, this has definitely piqued my interest in GraalVM, I have seen some polyglot examples on the official website, depending on the overhead it is going to enable some very interesting use-cases. Very excited to see where this goes.
Saw a presentation from the Azul guys about Zing last year. They have a very impressive product, and the number of ex-Sun engineers is reassuring. They also seem to have a good relationship with Oracle.
Among the repackaged OpenJDK offerings, Zulu is at the top of my list.
https://developers.redhat.com/blog/2018/09/24/the-future-of-...