I'll contradict everyone here: You figure it out on a case-by-case basis.
Generally, risks go down over time and with broad use. SQL, as a technology, is 100% risk-free, having been around forever, and widely used. COBOL is high risk, since while it's been around forever, hardly anyone uses it anymore, at least on modern projects. Moving your Cobol app to Android is fraught with unknown-unknown risk. Something that's been around 2-3 years is generally much lower risk than something which came out last year, and a good 10 years drives risks down further most of the time, but not always. It depend on whether people seem happy with it. Mongo seemed like a really good idea first few years, until people figured out (1) it had wonky performance issues (2) it was really hard to query for some type of queries (3) and what was the problem with postgresql again (it seems to do JSON pretty well too!)? Things change too. Java was the bedrock, stable, safe choice. It wasn't the fastest to code in, it was a bit clunky, but it was THE safe choice, and enterprises flocked to it. That is until Sun died, Oracle happened, and litigation+monetization kicked up to try to treat Java as a cash cow.
The flip side is why would you use it? When I was building an app a while back, I chose React although React Native had just come out at that point. It let me build the app once, and run on web, Android, and iOS, instead of 3 times. I figured cost savings of building and maintaining one codebase outweighed the risks. On the other hand, in most cases, the upsides of switching away from Python -- now three decades old -- are usually negligible, so with the exception of a specific need (run-anywhere, above), I almost never pick something different.
And the final piece is code complexity, abstraction, and modularity. I don't feel bad adapting new numerical algorithms. It's usually a few hundred lines of self-contained code. If a better algorithms comes out, I might swap it out anyways. On the other hand, a programming language or framework is a lifetime commitment.
You work through all the risks and upsides, figuring maintenance is 90% of the cost, and you sometimes end up around the rules-of-thumb everyone gave. But not always.
Trick is to learn probability. It give a good mental framework for estimating expected costs and benefits. You don't usually do this explicitly with equations (what's the probability-Oracle-screws-us times costs-of-Oracle-screwing-us versus cost of upgrading to Python?), but it gives a language to think about risks.
Oracle created a brand new market in Java support contracts which didn't exist before, so that they could enter it and make a buck (wherein FUD is a standard sales tactic for them). They probably viewed their position on the OpenJDK as subsidising a public good, which in general is slightly out of character for Oracle.
Most enterprise vendors have, or will soon have, comparable products for sale. My employers have Pivotal Spring Runtime[0]. You can also get OpenJDK coverage from Red Hat[1], Amazon[2], Azul[3] and so on.
Incidentally I resent that I sometimes wind up defending Oracle's decisions. I think it was globally suboptimal but I can understand their reasoning.
Generally, risks go down over time and with broad use. SQL, as a technology, is 100% risk-free, having been around forever, and widely used. COBOL is high risk, since while it's been around forever, hardly anyone uses it anymore, at least on modern projects. Moving your Cobol app to Android is fraught with unknown-unknown risk. Something that's been around 2-3 years is generally much lower risk than something which came out last year, and a good 10 years drives risks down further most of the time, but not always. It depend on whether people seem happy with it. Mongo seemed like a really good idea first few years, until people figured out (1) it had wonky performance issues (2) it was really hard to query for some type of queries (3) and what was the problem with postgresql again (it seems to do JSON pretty well too!)? Things change too. Java was the bedrock, stable, safe choice. It wasn't the fastest to code in, it was a bit clunky, but it was THE safe choice, and enterprises flocked to it. That is until Sun died, Oracle happened, and litigation+monetization kicked up to try to treat Java as a cash cow.
The flip side is why would you use it? When I was building an app a while back, I chose React although React Native had just come out at that point. It let me build the app once, and run on web, Android, and iOS, instead of 3 times. I figured cost savings of building and maintaining one codebase outweighed the risks. On the other hand, in most cases, the upsides of switching away from Python -- now three decades old -- are usually negligible, so with the exception of a specific need (run-anywhere, above), I almost never pick something different.
And the final piece is code complexity, abstraction, and modularity. I don't feel bad adapting new numerical algorithms. It's usually a few hundred lines of self-contained code. If a better algorithms comes out, I might swap it out anyways. On the other hand, a programming language or framework is a lifetime commitment.
You work through all the risks and upsides, figuring maintenance is 90% of the cost, and you sometimes end up around the rules-of-thumb everyone gave. But not always.
Trick is to learn probability. It give a good mental framework for estimating expected costs and benefits. You don't usually do this explicitly with equations (what's the probability-Oracle-screws-us times costs-of-Oracle-screwing-us versus cost of upgrading to Python?), but it gives a language to think about risks.