This has been around for a few years and was one of the first so I think it is actually fairly widely used. It was the one I adopted for our products and I have stuck with it. I see it used a lot elsewhere too.
That said, it depends a bit which OS you are on. The Linux distros have gotten a lot better with their OpenJDK support in their package managers. So if I am using a bistro with the OpenJDK version I want, I will use that now.
> NEVERTHELESS, software supply chain is important. Whatever JVM one chooses should have a good answer to how they handle it.
We do agree on that. We also agree that Linux distributions & Docker official images have been doing shitty job in the past which is what your article is talking about. Thanks to Gil Tene continuous efforts to raise awareness about this issue, situation has somewhat improved.
My point is that AdoptOpenJDK has been specifically created to tackle those issues. Your initial comment seems very unfair to them and could misguide some people.
Everyone is free to pick the JDK build of their choice. Several projects do a good job at providing quality builds of OpenJDK. Most OpenJDK distributions are upstream first, so the determining factor is the trust you put in their build, test & QA processes. From that point of view and in a long term vision, supporting AdoptOpenJDK / Adoptium Temurin looks like a smart move because their tooling & processes are open source and which keeps the OpenJDK ecosystem in a safe state as it doesn't rely on a few private companies as sole providers for the community. History taught me that over reliance on Amazon or Azul might not be a good idea. Lets thanks them for their contributions, but lets no depend on them without viable alternatives.
> Your initial comment seems very unfair to them and could misguide some people.
Agreed, alas I cannot edit it anymore.
I was wrong in my understanding as to how the 'mystery meat' got into the flow. Having looked at the AdoptOpenJDK repos it's clear they do their work in the open. That's no guarantee, but is the best choice over the long term. And a JVM is a long term thing.
I’ve been favoring it for a while due to the clear support responsibility as a heavy AWS user, and avoiding Oracle licensing shenanigans around OpenJDK (one of their salescritters tried the “we notice you use OpenJDK a lot…” pushes insinuating that licenses might be required).
We use Amazon Corretto for our bootstrapped, profitable SaaS.
The reason is that we host on AWS Elastic Beanstalk, and this is the Java distribution that is supplied by default on Elastic Beanstalk's Java-based images.
Amazon Corretto is, for us, unremarkable, in a very positive way. Unremarkable in that we never encounter problems with it.
Totally off-topic but Corretto is the Italian word for a coffee with some liquor added, usually grappa (but it can be cognac, whisky etc). It also means "right" or "correct".
Even better, a "corretto" coffee is done at the origin to "correct" a coffee which was not brewed correctly. You hide the bad brew behind the added shot. Very nice double meaning for this Amazon distribution...
I miss Cornetto! The texture of the cream and the chocolatey bits at the top bring up very fond childhood memories. Also some of them IIRC have a solid chocolate bottom in the cone.
If you're not familiar with O, or wondering why an innocuous statement like the above strikes fear into people, it's not about just licensing Java. It's about their extortionate tactics and how they try to catch you in gray areas due to ambiguous wording in their terms and conditions, and demand fees for violating them.
I consider the reminder friendly, but definitely not what it implies... Any source on this? By guest services, you mean the additional "click this to install some custom stuff in the running VM so it works better" step? And if so, just after doing that, or VirtualBox in general?
I did a tiny amount of searching to verify this but came up empty handed. Guest additions (what I think you meant) is GPLv2, so it should be free for use.
The difficulty in distinguishing the two is likely intentional. At my previous org, Oracle sent a spreadsheet of IPs to my company's compliance department which they claimed were using the extension pack and so violated their license agreement. They demanded proof of the license.
The vast majority including I, only ever used guest additions (GPL).
> The difficulty in distinguishing the two is likely intentional.
That would not surprise me. Back when we were considering virtualisers many years ago, the issue was one of the reasons² I recommended against vbox despite using it at home - it felt a bit too dark-patterny¹ for my tastes. We went with a VMWare tool instead.
[1] though I'm not sure the term “dark pattern” had been coined, or if it had it was in my vocab, at that point
[2] another being Oracles general behaviour at the time - this was after their purchase of Sun and therefore Virtual Box.
Have run into this multiple times with them in multiple companies.
For those asking, it's about the "VitualBox 6.1.32 Oracle VM VirtualBox Extension Pack" - it's free to install but phones home and they reach out after a year or two of use and attempt to coerce you into paying for a license. Just ensure everyone has uninstalled it and tell them to go pound sand.
Those features are from VirtualBox Guest Additions.
VirtualBox Extension Pack, on the other hand, provides support for USB 2.0 and USB 3.0 devices, VirtualBox RDP, disk encryption, NVMe and PXE boot for Intel cards.
That article is just fud. OpenJDK any version is free to use for whatever reason, period.
If you use OracleJDK (which is pretty identical so unless you need support, go with OpenJDK), then you previously had to pay, but Oracle recently made the last version of it free to use. I mean, it really can’t get easier and freer. It is the same model as with Red Hat linux and fedora, hell, it is even more permissive as you can use the latest Red Hat version free of charge until the next one comes around (+1 year)
When a company Licensing is so complicated, that there are whole companies whose business case, is to help you negotiate with Oracle, it should make for pause and caution:
The company licensing around OracleJDK is complicated. OpenJDK remains licensed under GPL.
The only thing complicated here is that people seem to think that OracleJDK IS OpenJDK, it is not nor has it ever been.
OracleJDK is no different than Azul's JDK. It's a JDK vendored and supported by Oracle.
The long and short answer is, so long as you are using a JDK vendored by your operating system or a docker image that doesn't explicitly say "oracle jdk" you are and continue to be safe. There's no sneak lawyer trap that's going to spring. I've seen these claims ever since oracle bought sun and have yet to see oracle act in bad faith with their sun acquired open source software.
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
Note that, confusingly, there is a difference between “Oracle JDK” and “Oracle OpenJDK”. The latter has no restrictions, but only receives updates for six months (until the next major version).
First, you are muddying things because it’s not a product called OracleJDK vs a product called OpenJDK, it’s “Oracle’s download called (the) JDK” vs “a different download that can only legally be called OpenJDK.” More on that below.
It’s also more confusing than you indicate because you are excluding all historical context. The “regular” JDK everyone installed up until Java 8 was the “JDK downloaded from Oracle” and the open source OpenJDK was, for lack of better words, a knock-off with poor compatibility with a lot of enterprise software but used because you couldn’t include JDK in your distro’s package manager (even though it was completely free to use) because the license wasn’t GPL compatible. So everyone that cared about vendor-approved compatibility downloaded “the JDK” from Oracle as a tarball and used that. Those that were running home software could get away with using “apt install openjdk” instead.
After Java 8, Oracle pulled a huge switcheroo and said everyone should use OpenJDK instead, and their licensed customers could use the Oracle-provided JDK instead. They didn’t put it behind a paywall or even login, and left it available for free.
So if you missed the bit about OpenJDK being officially blessed to use or you continued to just go to Oracle.com to download “the JDK” for commercial use, you were now in violation. Some say Oracle licensing is never confusing by accident and the official recommendation to switch to a previously inferior alternative wasn’t a charitable move.
If you don’t know OpenJDK is what you want, you search for “JDK” and the only entity allowed to use the plain “JDK” moniker is Oracle. Even now, just Googling for “download JDK” gives you Oracle’s JDK (that’s twenty years of PageRank and inbound links pointing to what was once a “free” download - there’s no outranking that!) as the first result.
(Given Google’s IP history with Oracle, they should show “Did you mean OpenJDK?” and include those results too :D)
In the past the curse was “May you be recognized by people in high places”, nowadays it's "May Oracle learn of your existence". Nothing worse than learning that Joe Random from 3rd level techsupport installed Virtualbox, and now your entire organization is about to get audited by Oracle.
They were already doing some Java license auditing. Last year we were contacted about some small usage of Oracle JDK 8 they detected via auto-update checks from our corp IPs.
Our usage of Oracle Java 8 is classed as free still, and we pay Azul for the rest of our Java usage. I highly recommend Azul if you are looking for a vendor.
I don't think it's Oracle's coders that people worry about so much as its sales model and lawyers.
Particularly, that it makes it too easy for end-users to stumble into using components that do not come under its open source licence. This makes it a headache for organisations and users, because it is very difficult for an organisation to police "you can use X, but you musn't pass Y command-line flag that could invoke a non-free part" and other actions that could create a liability for the organisation (and a disciplinary row for the employee)
It's a little like deciding you're going to set up a sweet shop, give out free samples, and lay landmines one foot either side of the entrance.
If they historically used a model more similar to JetBrains or other companies that have a commercial open source product (where the program looks for a licence key in order to activate the non-free features, or where there is a completely separate install process for free and non-free versions) I expect they wouldn't face the same regular criticism. It's the 'Surprise! Lawyers!" aspect that people find stressful and unattractive.
With JDK builds, this separation of free and non-free product is what the community has essentially provided: if you install something like Adoptium Eclipse Temurin, you can be a bit more confident it hasn't bundled non-free programs that could create a financial liability alongside it. You could try to track which Oracle downloads are what, but they've changed their licence from time to time, so some people find it easier simply to differentiate by what organisation provided the packaged JDK.
A: Corretto is a distribution of Open JDK with patches included by Amazon that are not yet integrated in the corresponding OpenJDK update projects. We focus on patches that improve performance or stability in OpenJDK, chosen based on Amazon's observations running large services.
Q: What kinds of patches does Amazon intend to include in Corretto?
A: Patches will include security fixes, performance enhancements (e.g., speeding up frequently-used functions), garbage collection scheduling, and preventing out-of-memory situations, as well as improved monitoring, reporting, and thread management.
They maintain a page for each version listing patches. I don't believe it's up for 18 yet, but given the short list for 17 I expect it's currently just patching the vendor metadata.
Edit: While not technically a patch, I should note that they do have different compile options than the Oracle builds. The biggest difference I can think of is Amazon ships with the Shenandoah GC enabled, while Oracle's builds do not.
One patch (back in Corretto 11) relates to arm64, the CPU architecture that their Graviton EC2 instances (m6g/r6g/c6g/etc) use. It significantly reduces lock-related context-switch overhead and improves performance of high-concurrency Java applications as a result. Replacing OpenJDK 11 with Corretto can reduce CPU utilization of Kafka brokers on that platform by up to 20%.
An alternative to the standard JDK that's supported by Oracle. Generally, the less stuff Oracle controls, the better (not to say Amazon having control is inherently better, but imo, it's better than Oracle)
I think you are talking about their other offers? I was referring to ones at the bottom of this page under section: "Download Azul Zulu Builds of OpenJDK"
Apparently Oracle changes the license of their openjdk builds a while ago, so big corps decided it'll be safer to maintain their own jdk build in case Oracle's lawyers come knocking.
They mention a new alternative to JNI for interfacing with external code and data. For anyone else that'd like a bit more info, here is the JEP (which still has it marked as in incubation):
That was the whole idea of the Dart VM, by the way: to bridge the gap between the maximum performance you could get out of JavaScript and what you could get of a more statically-typed language. My recollection from a few years ago was that there was about a 2x performance gap between V8 and HotSpot. (All three VMs efforts: HotSpot, V8, and the Dart VM, were led by Larks Bak, by the way). I don't know if that gap has shrunk, grown, or has remained the same.
Yeah, it was a good idea. Given that Typescript is mostly consensus at this point, I'd argue trying to integrate it into the language spec is the better approach vs introducing a new language.
But maybe there are technical reasons why it's not feasible
So, what's interesting is that static typing buys you somewhat minimal gains in performance. This is why dart 1 shipped with what they called "optional typing".
The thing Dart "fixed" in terms of performance is it forced consistent typing. It removed the ability to add/remove/change fields/methods on an object at runtime. The Achilles' heel of javascript (at least, when I got hype on dart years ago) is how stupidly easy it is to change the memory shape of any object. That means the VM can't generally lay out memory for an object in a compact form. Further, the VM has to do a bunch of checks before it can go down the optimized path (in case assumptions are invalidated).
For a consistent type system, the only check needed is "is this object shaped like I think it should be?" and then you go from there.
I think the most disappointing part of Dart is that all that effort was spent creating a new language when what the browser needed (and still needs) is a new bytecode. I'd love to see WASM reach the point of a universal bytecode but fear that it painted itself into a corner by first targeting memory managed languages.
> what's interesting is that static typing buys you somewhat minimal gains in performance.
There are a lot of caveats here. You could potentially claim "minimal gains in peak performance if you can apply adaptive JIT compilation techniques", but even that is stretching it somewhat.
Adaptive JITing comes at a price in terms of warmup, memory usage and implementation complexity. Fixed object shapes help somewhat to reduce the amount of checks needed but they don't take you all the way there. Optimising numerics remains challenging (e.g. think about optimising the case where a field always contains a `double` floating-point value or a field that always contains a 64-bit integer value). Knowing the shape of the container does not yield any information about the shape of elements which implies that some checks have to stay behind in the loops. Yes, monomorphic checks are usually simple (compare+branch) but polymorphic are not. And so on and so forth.
Yes, Dart 1 is easier to compile into efficient code compared to JavaScript. Dart 2 is even easier though - because it is more statically typed.
> but fear that it painted itself into a corner by first targeting memory managed languages.
I've not been tuned in. Is there some good forward progress there? It along with threads felt stalled out. I'd love to see GC adopted as that would, IMO, turn WASM into something close to a universal bytecode. It would significantly expand the number of languages that could reasonably target WASM.
The extension has recently reached Stage 2 - most of the questions around type system have been resolved. V8 has a working implementation. We have build `dart2wasm` compiler targeting this and it shows good numbers.
There's no incompatible changes that AWS does that could lock you in. They're just changing the vendor strings, and for older builds back-porting fixes that are important to them.
The only major difference is Corretto enables an alternative GC, Shenandoah, which was originally implemented by RedHat. This has been mainlined for a long time now, but Oracle does not ship it. It is available in the Azul and RedHat builds as well.
104 comments
[ 2.9 ms ] story [ 164 ms ] threadI'm not sure how I never heard about this before now. Is anyone out there using this over other JDKs?
That said, it depends a bit which OS you are on. The Linux distros have gotten a lot better with their OpenJDK support in their package managers. So if I am using a bistro with the OpenJDK version I want, I will use that now.
https://news.ycombinator.com/item?id=19955958
NEVERTHELESS, software supply chain is important. Whatever JVM one chooses should have a good answer to how they handle it.
We do agree on that. We also agree that Linux distributions & Docker official images have been doing shitty job in the past which is what your article is talking about. Thanks to Gil Tene continuous efforts to raise awareness about this issue, situation has somewhat improved.
My point is that AdoptOpenJDK has been specifically created to tackle those issues. Your initial comment seems very unfair to them and could misguide some people.
Everyone is free to pick the JDK build of their choice. Several projects do a good job at providing quality builds of OpenJDK. Most OpenJDK distributions are upstream first, so the determining factor is the trust you put in their build, test & QA processes. From that point of view and in a long term vision, supporting AdoptOpenJDK / Adoptium Temurin looks like a smart move because their tooling & processes are open source and which keeps the OpenJDK ecosystem in a safe state as it doesn't rely on a few private companies as sole providers for the community. History taught me that over reliance on Amazon or Azul might not be a good idea. Lets thanks them for their contributions, but lets no depend on them without viable alternatives.
Agreed, alas I cannot edit it anymore.
I was wrong in my understanding as to how the 'mystery meat' got into the flow. Having looked at the AdoptOpenJDK repos it's clear they do their work in the open. That's no guarantee, but is the best choice over the long term. And a JVM is a long term thing.
The reason is that we host on AWS Elastic Beanstalk, and this is the Java distribution that is supplied by default on Elastic Beanstalk's Java-based images.
Amazon Corretto is, for us, unremarkable, in a very positive way. Unremarkable in that we never encounter problems with it.
Because oddly enough Beanstalk only supports Corretto 11: https://docs.aws.amazon.com/elasticbeanstalk/latest/platform...
https://docs.aws.amazon.com/corretto/latest/corretto-18-ug/d...
https://www.theregister.com/2022/03/22/oracle_starts_to_incl...
If you're not familiar with O, or wondering why an innocuous statement like the above strikes fear into people, it's not about just licensing Java. It's about their extortionate tactics and how they try to catch you in gray areas due to ambiguous wording in their terms and conditions, and demand fees for violating them.
It is presumably referring to “VirtualBox 6.1.32 Oracle VM VirtualBox Extension Pack”:
> Support for USB 2.0 and USB 3.0 devices, VirtualBox RDP, disk encryption, NVMe and PXE boot for Intel cards.
> The Extension Pack binaries are released under the VirtualBox Personal Use and Evaluation License (PUEL).
ref: https://www.virtualbox.org/wiki/Downloads
The vast majority including I, only ever used guest additions (GPL).
That would not surprise me. Back when we were considering virtualisers many years ago, the issue was one of the reasons² I recommended against vbox despite using it at home - it felt a bit too dark-patterny¹ for my tastes. We went with a VMWare tool instead.
[1] though I'm not sure the term “dark pattern” had been coined, or if it had it was in my vocab, at that point
[2] another being Oracles general behaviour at the time - this was after their purchase of Sun and therefore Virtual Box.
For those asking, it's about the "VitualBox 6.1.32 Oracle VM VirtualBox Extension Pack" - it's free to install but phones home and they reach out after a year or two of use and attempt to coerce you into paying for a license. Just ensure everyone has uninstalled it and tell them to go pound sand.
VirtualBox Extension Pack, on the other hand, provides support for USB 2.0 and USB 3.0 devices, VirtualBox RDP, disk encryption, NVMe and PXE boot for Intel cards.
If you use OracleJDK (which is pretty identical so unless you need support, go with OpenJDK), then you previously had to pay, but Oracle recently made the last version of it free to use. I mean, it really can’t get easier and freer. It is the same model as with Red Hat linux and fedora, hell, it is even more permissive as you can use the latest Red Hat version free of charge until the next one comes around (+1 year)
"Oracle Java Release 17 Is it Free Again?"
https://www.softwareone.com/en/blog/all-articles/2021/09/20/...
The only thing complicated here is that people seem to think that OracleJDK IS OpenJDK, it is not nor has it ever been.
OracleJDK is no different than Azul's JDK. It's a JDK vendored and supported by Oracle.
The long and short answer is, so long as you are using a JDK vendored by your operating system or a docker image that doesn't explicitly say "oracle jdk" you are and continue to be safe. There's no sneak lawyer trap that's going to spring. I've seen these claims ever since oracle bought sun and have yet to see oracle act in bad faith with their sun acquired open source software.
"Java Is Still Free 3.0.0 (Oct 2021)":
https://medium.com/@javachampions/java-is-still-free-3-0-0-o...
It literally says that in the very article you claim to be FUD. Have you even bothered to read it? Because it says everything that you did.
> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
Oracle has a FAQ here: https://www.oracle.com/java/technologies/javase/jdk-faqs.htm...
It’s also more confusing than you indicate because you are excluding all historical context. The “regular” JDK everyone installed up until Java 8 was the “JDK downloaded from Oracle” and the open source OpenJDK was, for lack of better words, a knock-off with poor compatibility with a lot of enterprise software but used because you couldn’t include JDK in your distro’s package manager (even though it was completely free to use) because the license wasn’t GPL compatible. So everyone that cared about vendor-approved compatibility downloaded “the JDK” from Oracle as a tarball and used that. Those that were running home software could get away with using “apt install openjdk” instead.
After Java 8, Oracle pulled a huge switcheroo and said everyone should use OpenJDK instead, and their licensed customers could use the Oracle-provided JDK instead. They didn’t put it behind a paywall or even login, and left it available for free.
So if you missed the bit about OpenJDK being officially blessed to use or you continued to just go to Oracle.com to download “the JDK” for commercial use, you were now in violation. Some say Oracle licensing is never confusing by accident and the official recommendation to switch to a previously inferior alternative wasn’t a charitable move.
If you don’t know OpenJDK is what you want, you search for “JDK” and the only entity allowed to use the plain “JDK” moniker is Oracle. Even now, just Googling for “download JDK” gives you Oracle’s JDK (that’s twenty years of PageRank and inbound links pointing to what was once a “free” download - there’s no outranking that!) as the first result.
(Given Google’s IP history with Oracle, they should show “Did you mean OpenJDK?” and include those results too :D)
Our usage of Oracle Java 8 is classed as free still, and we pay Azul for the rest of our Java usage. I highly recommend Azul if you are looking for a vendor.
It is incredible how people keep missing the picture about OpenJDK main contributer.
Particularly, that it makes it too easy for end-users to stumble into using components that do not come under its open source licence. This makes it a headache for organisations and users, because it is very difficult for an organisation to police "you can use X, but you musn't pass Y command-line flag that could invoke a non-free part" and other actions that could create a liability for the organisation (and a disciplinary row for the employee)
It's a little like deciding you're going to set up a sweet shop, give out free samples, and lay landmines one foot either side of the entrance.
If they historically used a model more similar to JetBrains or other companies that have a commercial open source product (where the program looks for a licence key in order to activate the non-free features, or where there is a completely separate install process for free and non-free versions) I expect they wouldn't face the same regular criticism. It's the 'Surprise! Lawyers!" aspect that people find stressful and unattractive.
With JDK builds, this separation of free and non-free product is what the community has essentially provided: if you install something like Adoptium Eclipse Temurin, you can be a bit more confident it hasn't bundled non-free programs that could create a financial liability alongside it. You could try to track which Oracle downloads are what, but they've changed their licence from time to time, so some people find it easier simply to differentiate by what organisation provided the packaged JDK.
This is like going for CentOS to work around Red-Hat doing most of the work.
FAQ: https://aws.amazon.com/corretto/faqs/
Downloads: https://docs.aws.amazon.com/corretto/latest/corretto-18-ug/d...
Q: How is Corretto different from OpenJDK?
A: Corretto is a distribution of Open JDK with patches included by Amazon that are not yet integrated in the corresponding OpenJDK update projects. We focus on patches that improve performance or stability in OpenJDK, chosen based on Amazon's observations running large services.
Q: What kinds of patches does Amazon intend to include in Corretto?
A: Patches will include security fixes, performance enhancements (e.g., speeding up frequently-used functions), garbage collection scheduling, and preventing out-of-memory situations, as well as improved monitoring, reporting, and thread management.
https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/pa...
https://docs.aws.amazon.com/corretto/latest/corretto-11-ug/p...
https://docs.aws.amazon.com/corretto/latest/corretto-17-ug/p...
Edit: While not technically a patch, I should note that they do have different compile options than the Oracle builds. The biggest difference I can think of is Amazon ships with the Shenandoah GC enabled, while Oracle's builds do not.
Change Log for Amazon Corretto 17 https://github.com/corretto/corretto-17/blob/develop/CHANGEL...
Change Log for Amazon Corretto 18 https://github.com/corretto/corretto-18/blob/develop/CHANGEL...
I found it by looking at their changelog for Corretto 11, which includes both their patches and the changes from mainline.
https://github.com/corretto/corretto-11/blob/develop/CHANGEL...
https://bugs.openjdk.java.net/browse/JDK-8186670
"Amazon Corretto, A Journey into Latency Reduction":
https://youtu.be/S4IrAZ5wT3c
I thought Azul was a bit more customised around the gc, so not quite the same JVM?
https://www.azul.com/downloads/?package=jdk
https://openjdk.java.net/jeps/419
JS/V8 is particularly impressive. I wonder how far we are from the theoretical performance limit on the software side?
I would guess we will eventually see deprecations of warts to improve engine performance further. Or integrated type system etc.
But maybe there are technical reasons why it's not feasible
The thing Dart "fixed" in terms of performance is it forced consistent typing. It removed the ability to add/remove/change fields/methods on an object at runtime. The Achilles' heel of javascript (at least, when I got hype on dart years ago) is how stupidly easy it is to change the memory shape of any object. That means the VM can't generally lay out memory for an object in a compact form. Further, the VM has to do a bunch of checks before it can go down the optimized path (in case assumptions are invalidated).
For a consistent type system, the only check needed is "is this object shaped like I think it should be?" and then you go from there.
I think the most disappointing part of Dart is that all that effort was spent creating a new language when what the browser needed (and still needs) is a new bytecode. I'd love to see WASM reach the point of a universal bytecode but fear that it painted itself into a corner by first targeting memory managed languages.
There are a lot of caveats here. You could potentially claim "minimal gains in peak performance if you can apply adaptive JIT compilation techniques", but even that is stretching it somewhat.
Adaptive JITing comes at a price in terms of warmup, memory usage and implementation complexity. Fixed object shapes help somewhat to reduce the amount of checks needed but they don't take you all the way there. Optimising numerics remains challenging (e.g. think about optimising the case where a field always contains a `double` floating-point value or a field that always contains a 64-bit integer value). Knowing the shape of the container does not yield any information about the shape of elements which implies that some checks have to stay behind in the loops. Yes, monomorphic checks are usually simple (compare+branch) but polymorphic are not. And so on and so forth.
Yes, Dart 1 is easier to compile into efficient code compared to JavaScript. Dart 2 is even easier though - because it is more statically typed.
> but fear that it painted itself into a corner by first targeting memory managed languages.
FWIW WASM GC is coming - and it looks great.
I've not been tuned in. Is there some good forward progress there? It along with threads felt stalled out. I'd love to see GC adopted as that would, IMO, turn WASM into something close to a universal bytecode. It would significantly expand the number of languages that could reasonably target WASM.
Time to work on bringing back java applets ;)
IntelliJ lets you download + install + switch between JDKS really easily, which I've found indispensable.
As another person commented, the Liberica JDKs with JavaFX built in are my go-to for hobby type coding.
If you don't use brew to install your software, you probably should start doing so.
Windows? Chocolately. https://community.chocolatey.org/packages/openjdk
The only major difference is Corretto enables an alternative GC, Shenandoah, which was originally implemented by RedHat. This has been mainlined for a long time now, but Oracle does not ship it. It is available in the Azul and RedHat builds as well.