Hacker News new | ask | show | jobs
by shadowgovt 1283 days ago
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.

2 comments

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.

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?
Well, while maven be a bit bigger, gradle has plenty of users as well, which uses groovy or kotlin for configuration.
Yes Maven uses XML.
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 ...

Most of the pieces we were using allowed for configuration via XML or code.

Predictably, the team therefore used both.

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/