5 ms·

> This combined with the fact that Java doesn't crash Huh? Doesn't crash in what way vs. C? I can still deref a null pointer and blow up. Java's perfectly fin

> This combined with the fact that Java doesn't crash 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.

plainnoodles 4y ago
One of the weird things about Java is that there's a big low-latency/high-performance Java community around that stems from Island (now owned by NASDAQ) using Java as the platform/language for their matching engine. Then, talent flow from that team resulted in lots of proprietary trading shops using Java to low-latency trading/order execution.
- SlipperySlope 4y ago
kaba0 4y ago
If you do that in C, your program may run “just fine” on the surface forever, yet it can silently corrupt all of its data. Java can catch NPEs and handle them appropriately (e.g. a web server might just answer server error 500, but it will continue to run with well-defined semantics). I don’t think the two is comparable. Even Rust will go off the happy path with a single use of unsafe, and there is no sailing back from there, while a Java program can’t crash in a UB-like way.
- icedchai 4y ago
  I guess you've never hit a JVM bug, then? They happen.
  - kaba0 4y ago
    Sure, but only with similar frequencies as an LLVM/compiler frontend bugs. A JVM bug may also be harder to debug, due to all the moving parts, but realistically, it’s always the program’s fault, and those are taken care of. 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).
mcculley 4y ago
I have worked on big projects with up to ~100 developers. On the C projects, someone's null-pointer dereference brings down the whole process. On the Java projects, the event handler or daemon thread has an exception handler at the top that logs the error and keeps executing. This is a huge difference in behavior. 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.
- pkolaczk 4y ago
  You can have a null pointer handler in C as well. 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.
  - mcculley 4y ago
    Yeah, I implemented an “atcrash” handler as a library which I embedded into multiple projects. But it was only so I could walk the stack, dump a stack trace into the terminal, and tell the user, “Please email this to the developer.” And then as cleanly as possible shut down the process. In C, as you say, not much else can be safely done.
    - pkolaczk 4y ago
      In Java if you encountered a null pointer exception or out of bounds error at the global level, there is also no guarantee you can safely continue, and dumping the stack and terminating is the only sensible option. Sure, the JVM is ok, but your app state might be already corrupt.
      - mcculley 4y ago
        This has not been my experience at all. 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.
vbezhenar 4y ago
Dereferencing null is undefined behaviour in C. Probably it could be handled with platform-specific code, but handling it correctly not the easiest thing to do. Other than dereferencing null, there're so many ways to accidentally blow up C code and something like reading uninitialised memory is truly undefined behaviour which can't be worked around. 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.
- tomohawk 4y ago
  I've never seen Java code in production handle NPEs, OOMs or other such conditions well. It's a shame Java does not have value types, which makes nulls a much rarer thing to have to deal with.
- icedchai 4y ago
  In theory, yes, but when you run low on memory (heap, PermGen space, whatever), you can run into unusual situations. You may have a bunch of threads spinning with exceptions, continually retrying, making no progress. You'll have no choice but to kill -9 your process and restart.

plainnoodles 4y ago

One of the weird things about Java is that there's a big low-latency/high-performance Java community around that stems from Island (now owned by NASDAQ) using Java as the platform/language for their matching engine. Then, talent flow from that team resulted in lots of proprietary trading shops using Java to low-latency trading/order execution.

SlipperySlope 4y ago

kaba0 4y ago

If you do that in C, your program may run “just fine” on the surface forever, yet it can silently corrupt all of its data. Java can catch NPEs and handle them appropriately (e.g. a web server might just answer server error 500, but it will continue to run with well-defined semantics). I don’t think the two is comparable. Even Rust will go off the happy path with a single use of unsafe, and there is no sailing back from there, while a Java program can’t crash in a UB-like way.

icedchai 4y ago
I guess you've never hit a JVM bug, then? They happen.
- kaba0 4y ago
  Sure, but only with similar frequencies as an LLVM/compiler frontend bugs. A JVM bug may also be harder to debug, due to all the moving parts, but realistically, it’s always the program’s fault, and those are taken care of. 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).

mcculley 4y ago

I have worked on big projects with up to ~100 developers. On the C projects, someone's null-pointer dereference brings down the whole process. On the Java projects, the event handler or daemon thread has an exception handler at the top that logs the error and keeps executing. This is a huge difference in behavior. 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.

pkolaczk 4y ago
You can have a null pointer handler in C as well. 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.
- mcculley 4y ago
  Yeah, I implemented an “atcrash” handler as a library which I embedded into multiple projects. But it was only so I could walk the stack, dump a stack trace into the terminal, and tell the user, “Please email this to the developer.” And then as cleanly as possible shut down the process. In C, as you say, not much else can be safely done.
  - pkolaczk 4y ago
    In Java if you encountered a null pointer exception or out of bounds error at the global level, there is also no guarantee you can safely continue, and dumping the stack and terminating is the only sensible option. Sure, the JVM is ok, but your app state might be already corrupt.
    - mcculley 4y ago
      This has not been my experience at all. 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.

vbezhenar 4y ago

Dereferencing null is undefined behaviour in C. Probably it could be handled with platform-specific code, but handling it correctly not the easiest thing to do. Other than dereferencing null, there're so many ways to accidentally blow up C code and something like reading uninitialised memory is truly undefined behaviour which can't be worked around. 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.

tomohawk 4y ago
I've never seen Java code in production handle NPEs, OOMs or other such conditions well. It's a shame Java does not have value types, which makes nulls a much rarer thing to have to deal with.
icedchai 4y ago
In theory, yes, but when you run low on memory (heap, PermGen space, whatever), you can run into unusual situations. You may have a bunch of threads spinning with exceptions, continually retrying, making no progress. You'll have no choice but to kill -9 your process and restart.