Huh? Doesn't crash in what way vs. C? I can still deref a null pointer and blow up.
Java's perfectly fine, and I have no idea why you'd write C any more, but if you care about (extreme) performance and not crashing, Rust seems the obvious modern choice here.
To directly answer you though, no, I haven’t hit a JVM bug that was apparent (so no segfault or anything like that, except when playing with sun.misc.unsafe).
Sometimes, you want to fail fast and be forced to fix that bug. More often, I want to keep doing whatever I can to test and develop the system and find more bugs without restarting the whole thing.
But this is generally not a good idea. I find software that does not crash early and visibly but instead tries continuing despite an obvious bug very brittle and often causing trouble because it can take a long time before operators notice the problem. If you accumulate enough bugs of this type, you get a mess that "kinda works" but is full of surprises.
The JVM is not corrupted by a NPE or out of bounds access unless you are using native code.
For example, I worked on a large X-Windows/Motif application with many developers. If some library dereferences a null pointer, it is game over. Kill the app. In a Java Swing app we built for a similar use case, we just trap the exception in the AWT event dispatcher, log it, and keep going. Yes, sometimes an exception has ruined the global state in some catastrophic way, but this is rare. We can keep running and debugging without restarting the whole app.
Another example is a web app: Any exception that bubbles up to the main request handler loop is likely (in our architecture) to happen before any change is made to the persistent store. Log it and handle another request. This makes debugging a lot easier than restarting the whole app.
This has been my experience with software written in Java by developers who think it was not their experience.
> In a Java Swing app we built for a similar use case
...oh no. I actually tend to associate Swing UI with weird, undefined behaviors, and whenever I'd look under the hood, it would nearly _always_ be due to them trying to swallow runtime exceptions. Pure hubris, as far as I'm concerned.
> Another example is a web app: Any exception that bubbles up to the main request handler loop is likely (in our architecture) to happen before any change is made to the persistent store. Log it and handle another request.
Please, please, _PLEASE_ just crash the server. The OS will handle it, it will be OK, and systemd will even do the right thing and give up if your thing crashes _persistently_, including all the fancy stuff like keeping track of how often it crashes.
I've done too much cleaning up after overly-confident superstar architects, your examples just brings painful memories. I beg you stop trying to be clever and just log the error and crash the app.
You seem to have a lot of opinions about my apps from your own unfortunate experiences. Hubris is a word that brings to mind.
And if it’s professional environment - that creates _powerful_ biases. Essentially, I’ve seen apps with developers acting _exactly_ like you, up to and including the line about logs. You might be the one exception - but somehow I doubt it, and I certainly won’t trust your word on it. Automatically logging desktop activity makes me trust you less, if anything. In particular, I don’t believe you prioritize issues the way your users do. That would, literally, be a first.
Again, you seem have very strong opinions on incorrect assumptions. I’m kinda bemused by that.
But if your code invoked an NPE or bounds check, then it means either the algorithm is incorrect or the data it processes are already corrupt by incorrect processing earlier. Continuing in such situation increases the risk, because you don't have any guarantees which parts of the application state might have been already corrupted by the bug. I've seen many many times an NPE was a result of a shared data corruption caused by a data race. JVM does not guarantee thread state isolation, so one bug can break the state of all threads.
> Log it and handle another request
That gives you only a false sense of safety. A Java app (and any other app) may die for many other reasons you can't handle. You need to be prepared for that anyway if you want a reliable service. But if you are prepared for that, and your server can restart in 0.1 second, you don't win anything by recovering from NPEs.
Being able to handle it correctly is just an additional benefit.
Your Java program may continue along silently, with corrupted application state, because it invoked a race condition, and you might never learn of the problem.
You can't get out-of-thin-air primitive values (no word tearing).
But you can still observe states that cannot be explained by any possible sequential interleaving of your program. E.g. your program can do:
a = 0;
b = 0;
a = 1;
b = 1;
print(b)
print(a)
Why a corruption at a structure level should be considered less serious than tearing at a word level?
Java does not have undefined behaviour at all. Dereferencing null would throw NPE which is ordinary exception, completely fine to handle or suppress or whatever. There's no concept of uninitialised memory. The only sources of undefined behaviour in Java is calling native code or using unsafe methods which are very rare and usually located in well tested library code.
Even stack overflowing is defined behaviour and you can easily recover from it.
It's a shame Java does not have value types, which makes nulls a much rarer thing to have to deal with.