3 ms·

> java is very easy to troubleshoot compared to c, go, and rust All the worst and most time-consuming troubleshooting experiences of my life have involved Java

> java is very easy to troubleshoot compared to c, go, and rust All the worst and most time-consuming troubleshooting experiences of my life have involved Java. Whether staring at pages of obscure stacktraces that the JVM decided to vomit all over my screen, or hours on end with Oracle tech support troubleshooting why Java decided to throw a tantrum (followed by editing obscure Java XML config files). These days I just stay well away from Java.

nisa 6y ago
well yes... it's a learning curve and it takes a while but if you are familiar with the jvm and xml and to some degree spring-framework and reflection it's usally pretty easy to find a root-cause - you also have great tooling like async-profiler or just sending `kill -3 <pid>` to get a stacktrace. At least you've got a hill to climb upon instead of an empty field.
threeseed 6y ago
You know that none of that has to do with Java itself. It's the app whose stack traces you are looking at. And the app that decided to use XML config files.
- cle 6y ago
  It most definitely comes with the territory.
- lmm 6y ago
  But applications tend to feel the need to use XML config files because of the limitations of Java.
  - meddlepal 6y ago
    Please elaborate on those "limitations". I really haven't seen all that much XML in Java recently outside of legacy applications... there's libraries for loading config data from JSON, YAML, etc etc.
    - lmm 6y ago
      JSON, YAML, or XML, it's all the same crap. The fact that programmers are feeling the need to externalise their business logic into "config" files is a sign that the language has failed. In a decent language you would write logic or "config" in the language itself, because the language would be a comfortable medium for expressing things (this is the norm in Python for example - while a few overengineered pieces insist on using TOML or something, most Python libraries don't require any separate config, you just "configure" them the same way you do the rest of your programming, in Python).
slaymaker1907 6y ago
At least there is a stack trace as opposed to a segfault with no context.
- Gibbon1 6y ago
  I trap segfaults in my firmware, save off a stack trace, restart and then log it. Is very useful.

nisa 6y ago

well yes... it's a learning curve and it takes a while but if you are familiar with the jvm and xml and to some degree spring-framework and reflection it's usally pretty easy to find a root-cause - you also have great tooling like async-profiler or just sending `kill -3 <pid>` to get a stacktrace. At least you've got a hill to climb upon instead of an empty field.

threeseed 6y ago

You know that none of that has to do with Java itself. It's the app whose stack traces you are looking at. And the app that decided to use XML config files.

cle 6y ago
It most definitely comes with the territory.
lmm 6y ago
But applications tend to feel the need to use XML config files because of the limitations of Java.
- meddlepal 6y ago
  Please elaborate on those "limitations". I really haven't seen all that much XML in Java recently outside of legacy applications... there's libraries for loading config data from JSON, YAML, etc etc.
  - lmm 6y ago
    JSON, YAML, or XML, it's all the same crap. The fact that programmers are feeling the need to externalise their business logic into "config" files is a sign that the language has failed. In a decent language you would write logic or "config" in the language itself, because the language would be a comfortable medium for expressing things (this is the norm in Python for example - while a few overengineered pieces insist on using TOML or something, most Python libraries don't require any separate config, you just "configure" them the same way you do the rest of your programming, in Python).

slaymaker1907 6y ago

At least there is a stack trace as opposed to a segfault with no context.

Gibbon1 6y ago
I trap segfaults in my firmware, save off a stack trace, restart and then log it. Is very useful.