> Does the jvm offers guarantees like c++ does? I trust c++ more, because once it's compiled, there are much less uncertainties.

This seems backward to me. C++ has a great deal of undefined behaviour, which you don’t get in Java. And Java has had a memory model for years - until recently nobody could argue their parallel code was correct on C++.

If you want guarantees Java seems like the better option.

Exactly! also on my current project I have tried out different JVMs and the results where identical.

Oracle (HotSpot) GraalVM (also Oracle) Zing OpenJ9 ExcelsiorJET

Performance was radically different between them, but the answers where the same (ok equivalent as this a whole lot of parallel code).

My co-workers can't even get their C++ compiler to be accepted by two different compilers and it is not just them. Compiler upgrades are feared events where significant effort needs to be put in.

While even the hard upgrade to Java9 from 8 was 3 extra commandline switches on startup. For a project with 168 dependencies and more than 1 million lines of code. Done in one afternoon, with the upgrade to Java 11 taking 3 minutes. (needed to add java mail to the WAR/classpath instead of expecting it to be in the JDK)

Upgrades from 5->6->7->8 where equivalent or simpler. Eleven years in two bugs due to an upgrade. One a compiler bug in 1.7.45 an other not overriding all the methods from abstract list in a list of string implementation that uppercased on retrieval. Trivial compared to C++ upgrades.

Looks like you have not worked much on C++. C++ is literally one of the worst languages for undefined behaviour and when something does go bad, the tooling around the language is so horrendous that it takes days to debug something that can be done within hours in Java.

I spent close to a week on data corruption that would have never been possible in Java.

C++ is not for the weak of heart. It's like the wild west. I have since moved to the civilisation of Java and quite happy here.

While I really do like C++, generally, I see the question being whether to use Java or C#. And, for me, the answer to that question is always C#. It’s just a better language.

Sun open sourced a lot of software, but they didn’t co-operate with the community. When Oracle bought Sun, I remember thinking that they may have been the only company to have a worse open source background than Sun.

I’ll admit that Microsoft probably isn’t any better as far as actually being open (compared to throwing the source code over the wall on occasion?, but (1) they aren’t any worse, and (2) they never sued Google for using clean-room implementations of their programming language and libraries.

>I see the question being whether to use Java or C#.

I can't see why you have understand it like that, but I agree with the rest.

My guess is that both are "enterprise" languages with a large ecosystem and pool of users, and both have a fairly pragmatic blend of performance/productivity. It's fairly uncommon to see both used together as they tick many of the same boxes.

It is common in enterprise shops to have native UIs in WPF and the server side in Java with Web APIs.

Now with .NET Core that is slowly changing, but .NET Core still needs to catch up with many .NET Framework features, specially enterprise frameworks that run on top of .NET.

I could have phrased it better. When I want to write something where Java could be a good fit, I use C#. There are times I want to write something where Perl, Javascript, C, or C++ are good fits, but it’s very unusual for me to think “Java or C++ would be a good fit for this project.”

Good luck ensuring those guarantees across all these compilers, and it is only a partial list.

https://en.m.wikipedia.org/wiki/List_of_compilers#C++_compil...

What many think is ISO C or C++ is actually compiler specific behavior, because they never bothered to read the actual ISO, just some programming book.

> Good luck ensuring those guarantees across all these compilers, and it is only a partial list.

Why would you need to? Build your binary, test it, give it to your customers. Why do you have to test every compiler?

Because you actually need to use those compilers to sell your software?!

For example your carefully written C++ code with gcc, might crash and burn with the TI compiler that is the only way to target a specific SOC.

Or maybe that other customer doing HPC only accepts your code if compiled with Intel or IBM compilers.

> Or maybe that other customer doing HPC only accepts your code if compiled with Intel or IBM compilers.

Then you build it, test it and deploy it. No clue what you are on about.

Because most likely you lack the experience to what actually means writing portable C++ across several OSes with disparate C and C++ compiler toolchains.

Check Boost's codebase as an example of such portability efforts.

Are there many projects where people would be choosing between Java and C++ anymore? They have found their niches and there doesn't seem to be much overlap to me.

They are quite together if you're building a platform. You usually have C++ doing all the CPU intensive work/low level IO which is exposed through JNI for any higher level stuff (like web).

JNI >>> Any other interface to C/C++.

One thing is certain, once your C++ app is compiled to an architecture, it is guaranteed not to work anywhere else.

Completely agree, since there's no point in forking. If you fork Java the language, take a significant part of the community along with it and that hurts Oracle's business interests, they're pretty certain to go after users.

Due to Oracle's actions, Java is not free software any longer.

Java was never fully free, not even under Sun, it was only free beer for desktop platforms.