[pjmlp]

The big difference that many .NET Framework libraries won't work on .NET Core, and even less on Linux, because they depend on C++/CLI, Win32 interop or COM.

Then those corporations start to evaluate a rewrite to portable .NET Core and come to the conclusion that several third party components also don't work on .NET and they need to go shopping.

In the same process, they find out that said components actually have a perfectly working counterpart for Java since Java 1.4 or something.

And a new RFP goes out.

As for what to opt for, platform languages are always the best bet longterm.

As long as the platform is relevant on the market they stick around, guest languages come and go, and tend to be insignificant outside the platform where they have guest status as they have to reboot an whole new platform experience.

[pas]

Sorry, I worded my comment imprecisely. I meant the CRL and language feature developments can and should be looked at separately from the platform/ecosystem stuff.

I'm aware that Core is different, and that MS only ported a subset of their APIs, and thus many libs need to be completely rewitten, especially those that were already just wrappers/helpers for more Win32-specific things.

And this wrapping platform specific lower lever libs happens on other ecosystems too. Python users run into this quite a lot, Rust devs too, etc. And many early Java programs were basically platform specific, even if the JRE itself was not.