So it isn't like just exchanging one for the other like that.
.NET Core 3.0 will fix some of the compatibility issues but not all of them, for example EF 6 will only be partially supported (VS DB tooling is not being updated for Core).
Telerik and the likes I'm not so fussed about personally. I suppose DevExpress is another one on that list. I think front end component libraries like Prime-ng/PrimeReact are probably the way to go for the future of UI development for Line of Business applications.
Overall I reckon in a couple of years there won't be much of those blockers left at all.
It's the ridiculously large JVM ecosystem that makes Java awesome, not the language.
I have love for Java, but I gotta say it mostly is because the ecosystem is pretty fantastic. So much open source stuff for so long means it's all just there and it all just works. There are some gaps though.
.NET ecosystem isn't bad. It's pretty good. There are some phenomenal libraries. But sometimes the gaps are painful. The lack of an open source (read FREE) integration framework is a big one for me. There is BizTalk but that's commercial and probably expensive. Same with scheduling libraries. HangFire looks great but it's paid. A lot of the really high quality stuff you have to shell out for which when you're just hacking in your own time is not feasible. That being said there are open source libraries and some of them aren't bad. Lots of great stuff in general.
But the lack of ecosystem is killing them. And has been forever. The new MS CEO is great in my mind but it will take many years to turn the ship around. Devs don't forget.
Best example I can think of (was a C# guy for years). Resharper has been around forever. But it costs a lot. This is par the course for C#. I can get the same thing in Java by pulling in a few linters with Maven, and it's all free. Because MS scared away everyone that was afraid of licensing fees (ie most academics, the sharpest devs out there), there's nothing comparable.
Same with C# port of Quartz and so many others. They killed off the real rockstars among us that create the majority of libraries that everyone else uses.
Can it be fixed? I hope so. The CLR is great and Oracle sucks. But for now there's a good reason Java is dominant
They also have a perpetual license. If you cancel after the first year, you can keep using the version that was current 12 months ago.
But the one thing missing in Java is anything like LINQ. I don’t mean the syntax I am referring to the idea of LINQ -> expression trees -> third party providers that translate LINQ to another language (sql, Mongo Query, etc.).
I do miss LINQ though. The Java options are all clunkier because the type system isn't nearly as flexible
Person.Get(p => (p.Age > 65 && p.Sex == "M") || (p.Age > 63 && p.Sex == "F"))
public List<Person> Get(Expression<Func<Person,bool>> expression)
You get full compile time checking and IDE supported autocomplete.
The Java code "looks" like they do the same because they generate code to simulate method references instead. It's pretty clever and Javas code generation support for Annotation Processors is excellent and makes it possible to do this in a cross-ide cross-build-system way
LINQ and JOOQ/QueryDSL all work on plain data objects with fields. But with Java you do it on a pseudo object generated from your existing classes
All of these years I've been beating up on Java for lack of something akin to LINQ. I guess I'll have to find something else to complain about.....
Also, .net is more of a “pit of success” language — Java with all its legacy baggage requires a lot more knowledge to avoid mistakes.
Can you give some examples, that wouldn't be equally applicable to Java?
As Hejlsberg explained, the problem with virtual-by-default is that every time one of your public methods calls another public method on the same object, it makes it that much more complicated to reason about your invariants. If the called method is non-virtual, then you're in full control, and you know exactly what happens. But if it can be overridden, then you need to define a contract for overriders to follow, and you can't assume that it does anything other than what's expressed in that contract (in particular, you can no longer call that method without ensuring that all class invariants hold, even if it's expensive). Furthermore, the overriders often also need to know which other methods on the class do or do not call this method.
In practice, this is so much hassle that not even the Java standard library does that. For example, given ArrayList, if you override add(), does that affect addAll()? The docs don't say. So in practice, the only things that are safe to override is what the docs say are safe to override... which is to say, exactly like "virtual", except it's not enforced by compiler. Overriding random methods often works, but is a hack not dissimilar to using Reflection to access non-public members - even if it works, you're relying on implementation details of the class.