> All mayor features were available since v3. Though then the development stagnated and little new outstanding new featured were included in newer releases.

Are you serious? LINQ (okay, that was 3.5 IIRC), the TPL and async await fundamentally changed how I write C#.

Java might be source compatible, but sometimes it is quite fun to make libraries work across versions.

Specially if they rely on APIs that did break, like JDBC interfaces.

Also Android Java isn't 100% Java as Google cherry picks APIs, which with the increase of Java 8's adoption is increasing the effort to write portable libraries that compile against Java and Android Java.

Also Android Java runtimes don't understand the bytecodes introduced in Java 7 and 8. So you cannot use libraries that make use of them.

This will only get worse with Java 9 modularity and with the value types, reiffed generics and new FFI planned for Java 10.

The shithole Google has dug itself and its developers is pretty deep, yet they keep digging instead of partnering with either MS (for C#) or Oracle (for real Java) to get a sane modern language.

But we'll end up with one of the following suboptimal solutions: - half-assedly backported Java 8 features (with buggy bytecode transformers for libraries that are included in binary form) - either Dart, Go or (why not go full retard) JS

When you see their Google IO presentations or interviews, they re-iterate that Java is the only true way on Android, with the NDK just for games and implementation of Java native methods.

Then the usual answer to standard Java support is "What features matter to you? Get in touch with us".

Is it so hard to see that who usually asks that question cares about 100% of the language or at very least the compatibility profiles?

Android N supports Java 8: https://developer.android.com/preview/j8-jack.html

That is not 100% accurate.

Android N has partial support for Java 8, it doesn't support all the new Java 8 APIs nor new bytecodes.

Additionally, given that Android M is around 10% after one year, how long do you think Android developers can fully target Android N?

Note that .NET Core is, more or less by necessity, much smaller than the full .NET framework. The latter isn't going anywhere or being deprecated. Think of Core as just another subset of APIs that happen to also work really well on other platforms. We had that already with Silverlight, Client Profile, and other things.

Since .NET 4 introduced a new runtime (just as .NET 2 did; due to that I'd also say that 4 was not just a minor upgrade) all subsequent versions so far run on the same runtime and just change the libraries. MS got a bit of complaints for a confusing versioning scheme: .NET 2, 3, 3.5 that all used the same .NET 2 runtime, but had different library capabilities. It seems to me that they are doing this better with .NET 4: Every 4.x version runs on the .NET 4 runtime. .NET 5 will likely do the same again, once it is released.

They also changed another part: All .NET 4.x versions are drop-in replacements for .NET 4.0. That's why, when you look in the C:\Windows\Microsoft.NET\Framework directory, you see v1.0, v1.1, v2.0, v3.0, v3.5, but only a single v4.0, which on my machine is actually 4.6.(probably 1).

All this doesn't mean they cannot iterate on the runtime itself, though. Recently we got a new JIT for example, and I think the GC also got some upgrades. And keep in mind, this is the release announcement for .NET 4.6.2 – a minor upgrade over 4.6.1. Naturally you won't see major new features added.

____________________________

> Plus several APIs turned out to vanish pretty quickly and are dragged along as legacy like WinForms, Silverlight, WPF, Managed C++, ManagedDirectX and its next incompatible iteration, SharePoint APIs, WinFS, etc. Plus the incompatible different API WinRT aka WinRunTime aka UniversalRuntime with various incompatibilities in WinPhone8, Win8 & 10.

Most of those are completely separate products and are not part of the .NET Framework. You can argue that Microsoft is happy to create new APIs and let them die, but the vast majority of those are not in the actual framework.

____________________________

> In comparison Java is source compatible to at least v1.4,but in reality often back to Java 1.1 or 1.2.

Uhm, that very much depends on the features you use. Sure, if you eschew generics, auto-boxing, annotations, enums, foreach loops, and a lot of other language features. Especially 1.5 brought a lot of things that permeate many Java codebases. In 1.1 you'd have to live without collections, XML, regex, and a few other things. I don't doubt Java codebases exist that could meaningfully go back to that compatibility, but I'm not convinced they're that prevalent. (I know, especially in Enterprise, Java version uptake is slow. In my observation this currently amounts to Java 6 being the version usually used. Back when 6 was current, it was usually 1.4 and earlier.)

Java 1.5 is also twelve years old. A big chunk of that time is the stagnation after 1.6 when Sun was on the ropes and Oracle hadn't stepped up to make any improvements yet.

I was using the same cutting-edge version of Java for my high school AP classes as I was using in my senior year of college, which is sort of unheard of among the other actively supported and developed programming languages.