I'm perfectly capable of writing correct code by hand (be it XML or YAML), my problem is with the contents of the configuration files. Especially for the legacy Java EE servers there's loads of boilerplate stuff that has to be there for some reason but you don't have any idea why. Until something breaks and somewhere a magic setting has to be 'fixed'...
“Bad” is a value judgement. I’d go more with “taking on problems we don’t have” - J2EE made more sense if you were in a business like Atlassian’s where you sell an app to customers who wants to be able to run in it a bunch of different ways and configure many things without access to the source code. That especially made sense in the older era where apps were managed by sysadmins who didn’t have compilers and wouldn’t have gotten the source code from a vendor or wanted to pull it out of CVS.
That’s legitimate but, especially for open source developers, overkill and it pulls in a ton of maintenance work (e.g. I have several apps with a ton of CVEs in components which were never used but can’t be removed without breaking things, and thousands of lines of XML configuration which has to be analyzed to look for intentional customization to upgrade to the release version which has been patched. Now, maybe that’s doing it wrong but that’s multiple separate Java specialist development shops so it’s not just me being dense.).
Part of that is scope (Kubernetes does so much more) but most of it is the benefits of decades of experience and having a clean design. Java application servers were designed by and for Java applications so they blur a lot of lines whereas a Java (or Python or Node, etc.) developer can use Kubernetes without learning any Go tools.
