I assure you code as XML has not disappeared from enterprise Java.

It has not disappeared from enterprise and this has nothing to do with Java. XML is still very good as a document format, with powerful validation capabilities (XSD) and powerful language to do transformation of documents (XSLT), searching documents (XPath). It is still used for a reason.

In addition there are standard ways of encrypting/signing XML documents.

Those aren’t the parts that are used though - it’s the Spring XML as the replacement for the “new” keyword that is more likely to be found than XSLT or XSD.

Ironically, deployment, management, monitoring and security of a single (even clustered) EJB app server was a much more straightforward affair that today's cloud based Rube Goldberg machines that I encouter in practically every "modern" enterprise app.

Yep. For small projects, why is it so hard to have a "deploy to server" button next to "run locally" in my IDE?

I have been explaining to folks how OpenAPI is basically WSDL-lite. And is building up to be as big, at their current velocity. Kubernetes and friends, it is hard not to see as non JVM Glassfish servers. I remember WAR files being far easier to reason about than the current bundle setups we have today. SAR files were an amusing stab at the same thing, complete with the server managing deployment/startup order.

I still don't want to go back to that time, mind you. Is probably why I'm so hesitant on the current attempts.

Seriously, I work in ops with a side of coding and in order of "most pleasant" to "most annoying":

- Go and similar "one binary". Bonus points if static files are also embedded

- "Just a JAR with few parameters"

- Anything that comes pre-packaged in OS. Perl with OS-provided libs.

- Enterprise Java with code-as-xml for config. More pleasant if we're not the ones managing the XMLS

- C/C++ apps with reasonable deps that don't need re-compiling half of OS

- Bare containers. Shit visibility without a lot of tooling but at least we don't have fight deps

- k8s. Complexity of system rarely pays off with the relatively simple apps our devs are deploying and need even more tooling for good visibility

- Ruby outside of container - just fucking kill me. A bunch of requirements for libs in system just to compile "gems" (why those cunts can't call it libs like everyone else), long startup, leaks memory, took them 10+ years to make a web server that's not completely shit...

- Python - if I see something is in Python I try to find alternative solutions. I swear half of the install instructions either just don't work or shit all over home/system dirs. The absolute clusterfuck of py2-3 migration didn't help either, thankfully it appears its finally over. Bonus demerit if instructions mention setup.py. Tho to be fair I didn't tried recently, maybe it is better

> The IDE that's written in Java most likely shares nothing with Java ecosystem parts they "hate"

Most vocal java haters I had met were JavaScript programmers who knew basically nothing about Java. Their hate was purely cultural - they learned on discussion forums that they should hate java. But, they had literally zero knowledge whatsoever.

> purely cultural

oh, I got one to admit he was "intimidated" by Java.

Note: there is a subset of developers who have either hit one of Java/JVMs limitations, or, subscribe as a matter of professional judgement and taste to a school of programming (say FP) that is not a good fit to Java and JVM's orientation (classes, OOP). This subset is an informed subset and their feedback is reasonable and at times has helped Java/JVM move forward.

It’s funny but a lot of JS haters are Java devs. Which also don’t know a thing about JS, or at least think JS looks like in the 90s, with callback hells and whatnot.

I know both Javascript as well as Java. Java trumps JS by a mile

I don't particularly like Java (but I did love it back in 98 or so when I came across it, coming from C++), but it's mostly due to the proliferation of OO monstrosities created by architecture astronauts. The language itself is ok, if too verbose. The JVM is awesome when you use something like Clojure on top of it.

>> bunch of code-as-XML for configuration

Code as json or yaml is fundamentally the same while being nicer to look at (yaml at least).

It's a step back in a way. Code as XML had DTD with on the fly validation and autocomplete. JSON and YAML are still playing catch up in this area.

I have lots of biases against XML. For me it is nearly personified as Steve Balmer. However, it is rather funny to see people who hate XML yet love html (or even more absurd XAML). The autocomplete feature makes XML somehow not completely horrible as you can easily define a schema and get a kind of mini language with zero effort. Eventually the mind removes the tags and you are just left with the content. However, I see text formats that describe tree structures are all fundamentally the same. It is impossible for json, yaml to be waaaay better than XML as it is the exact same thing.

It's in a way more terrible as it usually is templating language + YAML

So you need to navigate pitfalls of YAML (or bear ugliness of JSON) all while learning a templating language.

All because someone decided "Users will not want to learn Python for DSL, let's give them YAML"...

Every single tool that went that route has that problem and every single one would be better served just picking <language> (Lua is nice and embeddable, just saying) and using it as DSL.

For the past several years, the Java enterprise development is very, very easy compared to the mess that is node.js nonsense. And if you are not happy with the JEE environment, you can continue to use frameworks like micronaut, quarkus etc.

For instance, in Quarkus, you can have a full REST application in about 12MB of RAM and running on the Graalvm.

In Spring (often looked at a heavy framework), this is the code required to write a full REST endpoint:

@SpringBootApplication @RestController public class DemoApplication {

@GetMapping("/helloworld") public String hello() { return"Hello World!"; } }

> The IDE that's written in Java most likely shares nothing with Java ecosystem parts they "hate"

IDK, I think the irony is you thinking IDEs wouldn't use those patterns. I bet you'll find tons of weird interfaces and abstractions in IntelliJ. It is a huge and complicated code base.