While .NET was pushed by Microsoft for everything else that didn't necessarily require the features of C++ and as such got a good focus in the whole stack and OS integration.
Sun like any other UNIX company, never understood the desktop, and the only OS stack they pushed Java was the network computer failed attempt and later on J2ME.
It was JEE (J2EE back then) that made it relevant again.
Oracle has always invested a lot in Java, they already quite a few Java based products in the early 2000. They were the first DBMS to support stored procedures in Java.
They also kept the Sun research labs going and will be integrating the Java JIT Graal into the standard JDK.
The Java Language Summit is taking place this week.
https://www.youtube.com/playlist?list=PLX8CzqL3ArzUY6rQAQTwI...
The problem is that Oracle designs languages for suits not jeans.
Sun was serious about write once run anywhere; Java is remarkably successful in that regard. Part of that was not including OS-specific functionality. We'll see how well MS does on that front.
Java is failure on the desktop, nowadays besides IDEs and a few FOSS tools there are hardly any applications done in Java on the desktop.
If Google hadn't forked it for Android, it would be yet another server language.
Besides Android, we only get RFPs for JEE projects nowadays.
Also all the features that should bring Java up to speed with the new generation of compiled languages in value types, generics and AOT compilation as standard toolchain feature are planned for Java 10 or later.
Why do you think Scala guys are exploring Scala Native?
Nowadays there are hardly any applications done on the desktop, full stop.
I agree that the JVM would benefit from being usable for a) command-line utilities that are lightweight enough to use in pipelines, and perhaps also b) decent native GUI applications (if you believe that niche is still important). But you don't need the capability for OS development to do those things. I mean, Python does those things. I don't think Scala Native is or should be serious about OS development.
The guys paying us didn't got the memo apparently.
Nor did the ones targeting Android, iOS and IoT LCD displays.
What is an IoT LCD Display and who is targeting them in the same way they target Android and iOS? Sounds like some class of hardware, but only thing I can find by searching is toy projects hooking up an LCD to a RaspberryPi or Arduino
They are targeting them the same way as iOS and Android in the sense that those type of applications are native to the underlying platform without any kind of browser playing the role of an OS.
Meanwhile Oracle could just as well rebrand themselves to Satan.
Years ago I thought people working in mono on Linux were just asking for trouble. Now it seems genuinely feasible to be running .Net on a non-Windows platform.
The short is: if you're going to do Mono, make sure that you're always having at least one person on the team doing Mono, otherwise there's a moderate chance that you'll lose the ability to run on Mono.
Also, stay away from entity framework. Some people might disagree, but we had problems with it and I hate that framework.
Every large team I've seen use it (EF) ends up with slow horrible queries generated that DBAs see hitting the database thinking WTF?
If you're doing web/api services, then mono/.net core are serviceable. Though I would recommend that you have CI/CD setup to use linux/mono if you are going to target that platform... for the most part if it works in linux its' going to work in windows, not so much the other way around.
Take this with a grain of salt, as I've been mostly node.js for a couple years now, though the progress with .Net core and VS Code have my interest.
However making things from scratch works totally awesome.
But then Mozilla started releasing versions every couple of months
The new dotNetCoreFramework 1.0 just got released. It wouldn't sense to add mayor new features to dotNetFramework 4.6x, legacy is written on the wall.
dotNetFramework 1x from 2002 to 2005 is unsupported for many years and APIs and code ate incompatible with dotNetFramework 2+. Basically dotNetFramework rebooted with v2 and got really popular starting in 2005. All mayor features were available since v3. Though then the development stagnated and little new outstanding new featured were included in newer releases. 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.
So Microsoft now has to maintain Win32 API and its subsystem (the reason why people are still using Windows, dating back to 1995 and source code compatible to Win16 API dating back to Win1 (1985) and Win16 is still supported on 32bit OS (technically it could also run on 64bit, if MS would want that). And UniversalRuntime (former WinRT) based on Win32 subsystem and still a lot less featurefull and little developer support and little apps - MS wants to push it, many hate it and almost all Windows applications continue as Win32 x84/64 applications even most games (Steam is big, the hate on WinStore is rightful). And dotNetFramework 2x+ the legacy big soup infested with dream buildings full of XML. And now dotNetCoreFramework in v1 still pretty rough and unfinished and the usual v1 were you want to wait for service pack 1 or v2.
In comparison Java is source compatible to at least v1.4, but in reality often back to Java 1.1 or 1.2. Sure there are some crufty APIs that got a better alternative that is recommend and several third party frameworks come and are now enterprise/legacy tools and newer things are now popular. While Java stagnated a bit with Oracle at times, it's still a nicer experience than the quickly vanishing and legacy API that Microsoft releases out en mass. And also Google is supporting Java on Android as its main API.
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.
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
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 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?
Are you serious? LINQ (okay, that was 3.5 IIRC), the TPL and async await fundamentally changed how I write C#.
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.)
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.
Now if Sun still owned Java that would be a fair assessment. They couldn't figure out what to do with the language.