[pron]

I won't argue over particular features because clearly it's a matter of personal preference and, working on OpenJDK, I'm biased, but a couple of points:

Since Java was introduced in 1995 until today, Microsoft's software framework has had about three or four drastic backward-incompatible "generations", depending how you count. Most Java code written in 1995 will run, with little or no change, on the current JDK 13, and would compile on JDK 13 with only minor changes.

Leaving aside the JDK 7 years (2006-2011) when Sun was struggling and then going through an acquisition, the rate of innovation on the Java platform is quite high. It's just that we emphasize other parts of the platform more than the Java language because that's where Java has always believed most of the value is. In the past five years Java has seen an exceptional new low-overhead, extendable profiling capability (JFR), groundbreaking new GCs (ZGC), and what is probably the biggest breakthrough in compilation technology of the past decade (Graal). Those are all huge developments, none of them affecting the frontend language in any way. An innovative, state-of-the-art runtime programmed with an intentionally conservative language has been Java's strategy from the beginning -- James Gosling called it a wolf in sheep's clothing (https://youtu.be/Dq2WQuWVrgQ) -- and it has worked quite well. One could argue that that's the only way to sell a wolf to such an industry. Indeed, despite some grumblings on HN, it seems like most software developers prefer it this way.

[snuxoll]

I have no love lost for Java the language, I find it cumbersome as hell to work in and as such all of my JVM work is done in Kotlin, but I appreciate having conservative and well-thought our evolution of platform features that ultimately effect all JVM languages; seeing as Java The Language is heavily tied into JVM semantics.

Quite frankly even with all the new features Microsoft has been putting into C# they’ve been prime to ignore the existing implementations in F#, leading to a clusterfuck of an ecosystem where I can’t use many C# libraries in my language of choice due to conflicts in implementation. I don’t have that on the JVM, I know I can use a Java library in Kotlin, Scala, Clojure, hell even Ceylon without huge headaches because they all share the same primitives.

Let other JVM languages incubate need language features, Java needs to be where they are eventually stabilized and standardized in how they work on the platform.

[BoorishBears]

>Since Java was introduced in 1995 until today, Microsoft's software framework has had about three or four drastic backward-incompatible "generations", depending how you count. Most Java code written in 1995 will run, with little or no change, on the current JDK 13, and would compile on JDK 13 with only minor changes.

That's exactly what's wrong with Java.

That's why we got "functional interfaces" instead of proper lambdas.

That's why we got half baked generics.

That's also exactly what I'm praising C# for.

They've paid that price 4 times, and every time they added so much value that it was easily worth it to their users.

Ask the average C# developer if they'd trade for Java's half baked lambdas and generics alone for none of those generations happening, and you'd get a resounding, no way in hell.

And C# stayed relevant in enterprise despite it, I've never seen an enterprise say "we're choosing Java because 4 times since 1995 they decided to add features so incredibly powerful language features and broke backwards compatibility.

The places that couldn't handle the changes needed are also the ones that would keep running an old runtime (and old JVM if they're using Java, because any upgrade = risk, backwards compat claims or not) as long as they want, security be damned.

.NET has an insane amount of "under the hood" innovation that has happened as well in all that time by the way, I'm speaking to the programming languages, not the runtimes and platforms that enable them. It's fairly straightforward to compare language features because they started in such similar places, comparing runtimes is a much less direct comparison.

[pron]

Whether that's "wrong" or "right" is a matter of opinion. But it's hard to argue with the fact that many more people seem to prefer Java's approach to Microsoft's. As to .NET's "insane under the hood" innovation, the platform is similar to what Java was about 10-15 years ago in terms of GC, JIT compilation and monitoring. .NET prefers changing the language, while Java prefers changing the platform. The two just have a different DNA. I've always felt that while there's a clear bottom-line "business" advantage to improving performance or observability, language features are almost always questionable because we can't find any evidence they make a real difference in practice. The main difference it seems to make is in the number of developers who vocally love or vocally hate a particular feature, and in giving a feeling of "vibrancy" to developers who perhaps sometimes care about their code more than about the program it's part of.

[phillipcarter]

I’d recommend spending some more time with .NET Core and comparing its performance characteristics (as of .NET Core 3.1). I think you’ll find it compares quite favorably, with recent advances like Span making a big difference. While it’s accurate to say the CLR has been behind on the desktop for a long while, the rekindled effort around advancing the runtime in .NET Core has paid off in spades and has only really just begun. It sounds like your impression is rooted in the desktop CLR, which is effectively frozen for compatibility reasons.

[pron]

I'm sure it has, but in the meantime Java is making great strides as well on multiple important fronts -- low-latency GCs, a next-gen JIT, AOT compilation, native ffi, low-overhead in-production profiling and lightweight concurrency, and the main problem with Microsoft's technologies remains that they break compatibility every five-six years or so. Now it's .NET Core, and it wouldn't be a bad bet to guess that in five years it will be something else. We're at a point where it's so hard to make changes with a big bottom-line impact (arguably there weren't too many such advances in the past twenty years) that very few actually justify breaking compatibility, and companies know that. So while smaller software can afford switching from one technology to the other, big "important" stuff requires a compatibility lifespan of at least ten if not fifteen years, something that Microsoft has never been good at. It's possible that with their focus shifting more to the backend with their cloud offering that would change, but it appears that their cloud strategy is to support all software platforms rather than focus on their own. That's why we see Microsoft now hiring engineers, as well as getting some CLR engineers, to contribute to Oracle's OpenJDK [1].

[1]: https://mail.openjdk.java.net/pipermail/discuss/2019-October...

[phillipcarter]

> something that Microsoft has never been good at

Well, you're certainly entitled to that opinion :)

As I said, I encourage you to explore .NET Core and its recent advances, especially now that the big runtime improvements made in recent years have proliferated throughout the standard library and new language features. While it's fair (and correct) to say that the Java runtime is ahead due to many years of focused improvements, I think you'll find the difference quite a bit smaller than it was back when .NET was focused mainly on Windows desktop software.

[pron]

I believe you re .NET Core, but I think that Microsoft shifting their focus to a backward-incompatible development platform (not Windows, on which they have a very good compatibility record) every five years or so is more than just opinion. I think that their record on that front speaks for itself. If you were a developer who always uses the current flagship MS development platform to develop a piece of software that you first wrote in 1999, by now you'd be on your fourth significant rewrite. TBF, Java also made one such misstep, with JavaFX Script in 2009, but that was corrected and reverted.

[BoorishBears]

Haha, the way you just handwave away the last few years of .NET/CLR/Roslyn/DLR changes means I've seen this is a waste of my time and will stop checking for replies

But uh yeah... what percentage of Java developers are still on Java EE 7, 8?

The "business advantage" is in things not changing. If you compare languages by business advantage then Java 1 wins because "we haven't had to waste money upgrading since the 90s!"

I'm going for something a little more meaningful, developer ergonomics, which you hand-wave away as not being valuable to a business (protip: if your developers get to care about their code that's a good thing, you'll find you can get better developers if you look for the ones who do)

[pron]

Putting aside which platform has better developer ergonomics -- something that's obviously very subjective -- you think that linguistic features that have not been found to make any significant impact are "more meaningful" than things that make software more valuable just because you feel very strongly about that? Also, seeing that I've been a professional developer for more than a couple of decades now, I hope you'll forgive me if I ignore your "pro" tip. Programmers who care about code are, indeed, often better than those who care about nothing at all, but if you want to hire good developers, you'll hire those who care about the product more than about code. They'll be much more expensive, though.

[ivanche]

> But uh yeah... what percentage of Java developers are still on Java EE 7, 8?

I hope around 90% or more, because Java EE 8 is the latest version of Java EE.

[BoorishBears]

Java (EE 7 or 8)...

[pjmlp]

Not all enterprises enjoy going through .NET rewrite cycles (Silverlight, WinRT, UAP, UWP, .NET Core).

To the point that in 2016 I got a couple of RFP to port from C# into Java for UNIX portability, in spite of .NET Core also being an option already.

Their reasoning being that with Java it would be a safer bet, while they couldn't be sure if .NET Core would ever be the last rewrite.

[pas]

It's perfectly possible to separate the language changes from the mindless API/platform/ecosystem churn.

.NET Core finally considers Linux, the server OS, which brings it to parity with the JVM. Will this be the final rewrite? Who knows.

Plus there is a lot of churn in Java land too (new libraries, rewrites of old libs, streams, libs becoming unmaintained, etc.), just big corps don't ever do any real maintenance.

I would probably opt to use Scala or Typescript instead of C# anyway. And Rust if there's some performance critical part.

[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.