4 ms·

Exactly this. Had to stand-up a server in Java recently. At some point I realized I was doing more programming via XML files and Spring decorators than via ac

Exactly this. Had to stand-up a server in Java recently. At some point I realized I was doing more programming via XML files and Spring decorators than via actual Java code. Mostly because Java itself isn't a great abstraction for a CRUD server.

twblalock 4y ago
If you did it recently, you should not have needed XML. Even a decade ago, XML-based configuration was on its way out. The transition from Spring to Spring Boot enabled us to use regular code to configure our injectors, for example. I haven't touched XML for nearly a decade as a full-time Java developer.
- rockemsockem 4y ago
  I've only ever developed Java at places that had their own infrastructure for everything, so this question may sound uninformed, but isn't Maven still the de-facto package manager used for most Java applications and isn't Maven configured with XML?
  - synthc 4y ago
    Yes Maven uses XML.
    - tannhaeuser 4y ago
      Yes it's using XML for all the wrong reasons - as a config and even scripting format (hello ant plugin) when XML is for markup/text. Fscking Maven doesn't even allow basic XML/SGML features such as entities/text macros. And yes Maven's pom.xml is used for package metadata on maven-central and elsewhere even if you don't use Maven directly. BUT I have to say, every project using gradle as alternative so far has receded into bizarre ad-hoc deployment scripting. Maybe that's just because gradle can do stuff that was hidden away in jenkins build files, but still ...
  - kaba0 4y ago
    Well, while maven be a bit bigger, gradle has plenty of users as well, which uses groovy or kotlin for configuration.
- shadowgovt 4y ago
  Most of the pieces we were using allowed for configuration via XML or code. Predictably, the team therefore used both.
StevePerkins 4y ago
- shadowgovt 4y ago
  I can only tell you my own lived experience, and that was it. It is possible there's a better way to do these things my team was unaware of (I was aping an existing server and replacing its RPC handlers with our own, not starting from scratch), but yep. XML and I can't be arsed to remember if they call their @-forms "decorators" or "annotations" because I use too many languages that have some variant of them to keep track. Point is, I wrote more of both than actual Java, and the annotations make debugging much harder than slapping a tracing debugger on. ETA I think the peer comments and this one underestimate the stickiness of methodologies in old languages. The fact that there are better ways to do it now is irrelevant... Because there was a previous best practice that is no longer a best practice, that best practice lives forever in the code bases and shared knowledge passed by peer review of existing institutions. Hell, I can go to my bookshelf and pull down two Java tutorials that show how to do an RPC server with Spring and XML... Once it's committed to paper, it lives forever. One can make the assertion that a team should be constantly developing their process, but management is a lot more comfortable with standing up a new server that looks exactly like the old one than with trying a new methodology that is unproven at this company. If for no other reason than so we don't have multiple ways to approach debugging servers depending on what team set it up.
- dang 4y ago
  Yikes! You can't attack someone like this on HN, regardless of how wrong they are or you feel they are. Obviously it's completely against the site guidelines. If you'd please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.
marginalia_nu 4y ago
XML is pretty rare in Java code written this side of 2010. Not that it doesn't exist, but the whole spring mess is not something you really have to touch to set something up in Java. I usually enjoy Spark[1] for bootstrapping a simple REST-like interface. There are other options, but in general, you don't really need glue-languages at all if you stray away from old-fashioned EE-style frameworks. [1] https://sparkjava.com/ https://sparkjava.com/

twblalock 4y ago

If you did it recently, you should not have needed XML. Even a decade ago, XML-based configuration was on its way out. The transition from Spring to Spring Boot enabled us to use regular code to configure our injectors, for example. I haven't touched XML for nearly a decade as a full-time Java developer.

rockemsockem 4y ago
I've only ever developed Java at places that had their own infrastructure for everything, so this question may sound uninformed, but isn't Maven still the de-facto package manager used for most Java applications and isn't Maven configured with XML?
- synthc 4y ago
  Yes Maven uses XML.
  - tannhaeuser 4y ago
    Yes it's using XML for all the wrong reasons - as a config and even scripting format (hello ant plugin) when XML is for markup/text. Fscking Maven doesn't even allow basic XML/SGML features such as entities/text macros. And yes Maven's pom.xml is used for package metadata on maven-central and elsewhere even if you don't use Maven directly. BUT I have to say, every project using gradle as alternative so far has receded into bizarre ad-hoc deployment scripting. Maybe that's just because gradle can do stuff that was hidden away in jenkins build files, but still ...
- kaba0 4y ago
  Well, while maven be a bit bigger, gradle has plenty of users as well, which uses groovy or kotlin for configuration.
shadowgovt 4y ago
Most of the pieces we were using allowed for configuration via XML or code. Predictably, the team therefore used both.

StevePerkins 4y ago

shadowgovt 4y ago
I can only tell you my own lived experience, and that was it. It is possible there's a better way to do these things my team was unaware of (I was aping an existing server and replacing its RPC handlers with our own, not starting from scratch), but yep. XML and I can't be arsed to remember if they call their @-forms "decorators" or "annotations" because I use too many languages that have some variant of them to keep track. Point is, I wrote more of both than actual Java, and the annotations make debugging much harder than slapping a tracing debugger on. ETA I think the peer comments and this one underestimate the stickiness of methodologies in old languages. The fact that there are better ways to do it now is irrelevant... Because there was a previous best practice that is no longer a best practice, that best practice lives forever in the code bases and shared knowledge passed by peer review of existing institutions. Hell, I can go to my bookshelf and pull down two Java tutorials that show how to do an RPC server with Spring and XML... Once it's committed to paper, it lives forever. One can make the assertion that a team should be constantly developing their process, but management is a lot more comfortable with standing up a new server that looks exactly like the old one than with trying a new methodology that is unproven at this company. If for no other reason than so we don't have multiple ways to approach debugging servers depending on what team set it up.
dang 4y ago
Yikes! You can't attack someone like this on HN, regardless of how wrong they are or you feel they are. Obviously it's completely against the site guidelines. If you'd please review https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and stick to the rules when posting here, we'd appreciate it.

marginalia_nu 4y ago

XML is pretty rare in Java code written this side of 2010. Not that it doesn't exist, but the whole spring mess is not something you really have to touch to set something up in Java. I usually enjoy Spark[1] for bootstrapping a simple REST-like interface. There are other options, but in general, you don't really need glue-languages at all if you stray away from old-fashioned EE-style frameworks. [1] https://sparkjava.com/ https://sparkjava.com/