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.

It most definitely comes with the territory.

But applications tend to feel the need to use XML config files because of the limitations of Java.

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.

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

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.

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

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