The problem with Java+XML isn't XML itself, it's that the Java community for a long time was pushing more and more critical code into XML, because doing non-trivial dynamic things in Java itself can be a huge pain. And so over time, enterprise Java apps became giant balls of XML+Java that would break at runtime if you missed an XML parameter or had a stray character somewhere. At that point, what benefit are you getting from Java's static typing? You lose much of the benefits of Java, and suffer twice as much from its drawbacks.

This is slightly better with the push away from XML and toward annotations, but it's not much better. Your program's behavior still depends on tagging the right language constructs with the right magic tags, which is a horrible way to program IMO.

> The problem with Java+XML isn't XML itself, it's that the Java community for a long time was pushing more and more critical code into XML

You are going to have to show some examples.

> because doing non-trivial dynamic things in Java itself can be a huge pain

Actually Java has always been a fairly dynamic language. If it wasn't you wouldn't have all the XML and annotation stuff but code generation like you do in C/C++ and to some extent Go.

You have to remember one of the reasons why there was a shit load of declarative configuration in old Java for enterprise is because software was on premise software. Customers would have different databases, hardware, etc. And there was no way you could say to those customers: "hey how about you go recompile this and that" or "use this syntactically weird DSL".

Really the only better enterprise option back in those days was Lisp we all know how that played out.

> Your program's behavior still depends on tagging the right language constructs with the right magic tags, which is a horrible way to program IMO.

I agree/disagree. It depends on context. Annotations are declarative and thus IMO easier to not screw up and even easier to understand in many cases. Particularly for serialization and code generation. Most languages now have some sort of annotations and this is for good reason.

But yeah too much (annotations) is a bad thing. Java now has annotation overload (spring boot).... probably because people bitched about XML :) ... pretty soon will have convention overload as well (Spring Boot is heading down that path as well like Rails).

You can always take the explicit programmatic option... you know like wiring up your own beans and writing manual SQL but people want "magic". There is probably an even ground somewhere.

I agree with cle, and I care enough to give examples of painful XML coding in Java:

* Spring startup config (this is basically coding in another XML-based language)

* JSPs (again, programming in a new XML-based language)

* Maven Config (IMO incredibly painful-to-use XML-based language)

* Hibernate config, mapping files

* Tomcat config (basically a pre-cursor to Spring in some sense)

Java is not a dynamic language, sorry. The JVM bytecode is fairly dynamic, but the language certainly isn't.

Also, I think Java would have been better off never introducing annotations. They have their uses, but they've been so over-abused that I would consider them a net negative on the language as a whole. I've been thinking about starting a blog, and one of my initial blog posts may be why annotations are bad for Java.

> * Spring startup config (this is basically coding in another XML-based language)

The alternative of manually wiring up beans or giving up and using shitty singleton patterns is pretty awful (remember this was preannotation days).

A pretty sexy annotation DI these days is Dagger2 but alas you seem to hate annotations.

> * JSPs (again, programming in a new XML-based language)

That is not an XML language unless you are talking about JSPX or JSF. It is a crappy templating language. Lots of languages have those (like PHP had Smarty or Pear...). I totally agree JSP and the future JSF was a horrible addition to Java.

> * Maven Config (IMO incredibly painful-to-use XML-based language)

A config that your IDE instantly knows how to properly setup and allows for massively powerful inheritance (see super poms). If you import a Maven project with Eclipse or IntelliJ it just works.

Now I admit Maven is verbose and has lots of baggage but it has some serious pros and a lot of those pros are actually because it uses XML (like Eclipse can automatically adjust your Maven file without changing formatting). I have scripts that I have written in many languages (bash, python, etc) that can read Maven POM files thanks to XML. You can't do this with Gradle.

> * Hibernate config, mapping files

Yep that sucked but you hate annotations... so I guess you propose programmatically doing the mappings?

I despite hibernate anyway.

> * Tomcat config (basically a pre-cursor to Spring in some sense)

Oh like Apache config is any better. I mean seriously Apache has made up weird SGML config.

> Java is not a dynamic language, sorry. The JVM bytecode is fairly dynamic, but the language certainly isn't.

It is a dynamic language. You can instantiate classes by string names and manipulate their bytecode on the fly. You can call methods dynamically as well. Yeah it doesn't have the ease of metaprogramming like Ruby or Python but its its there through libraries (CGLIB).

Honestly I'm not sure what you mean by dynamic (please cite something) but I guess you mean interpreted and even that is sort of wrong as well (bytecode is interpreted by the JVM).

> Also, I think Java would have been better off never introducing annotations

Annotations also allow for preprocessing aka light weight macros. A full macro system probably would have been better. I look forward to your blog post (in all honesty).

You asked for examples and that proceeded to defend almost all of the ones I listed, which basically proves my point that this is how things work in the Java community.

You can call things via reflection, therefore the language is dynamic? You have a strange definition of what makes a language dynamic. By that definition just about every language is dynamic. In C/C++ I can dynamically load symbols, call functions by string names, call C++ constructor functions, etc.

I've never in practice seen anyone use compile-time annotation processors. In practice, annotations define runtime global variables that some frameworks make use of by doing expensive classpath scanning on startup to add or rewrite bytecode at runtime. These frameworks basically help cement java's reputation for having incredibly slow startup times while at the same time making it very difficult to understand how your code works. Even if you aren't doing classpath scanning to generate code, using annotations also introduces unnecessary coupling in your code in practice. The blog post will have some good examples I've seen in the wild. :)

> In practice, annotations define runtime global variables that other frameworks can make use of by doing expensive classpath scanning on startup to rewrite bytecode at runtime.

Dagger2 is DI a compile time annotation library. Yes there needs to be a lot more libraries like this.

I totally understand some of your hate for annotations (I have my own with Spring Boot).

Despite my tone from the previous comment I think there should be a lot more plain old programmatic configuration (ie just load up objects and setup some properties during the bootstrap).

I had aspirations of making a howto guide using Dagger2 and various other compile time / code generation libraries (like jOOQ and MapStruct) as I too absolutely hate the classpath scanning hell that is Spring these days.

I can't deny though that some people find the "magic" more productive particularly for ramp up time.

All in all I violently agree with you more than you think (hence why I'm looking forward to your post).

I still don't know what a dynamic language is and neither does Wikipedia for that matter [1]. Its pretty nebulous. Its like saying strongly typed.

[1]: https://en.wikipedia.org/wiki/Dynamic_programming_language#E...

Dynamically typed languages carry the types of values at runtime. That is, whatever is executing your code can look at a value itself and read off the type of it. Statically typed languages check all of the types of their values at compile time to make sure that it's sound. Then, they can strip the type information from those values and execute them without having to perform any runtime checks. In a dynamically typed language, the way to apply an operation is to read the type tag on it first, make sure the operation you want to apply can be applied to it, and then execute that operation. In a statically typed language, that check happened at compile time, so you're safe to just apply the operation to the value. Oftentimes languages may not be fully statically typed or fully dynamically typed. Java's use of reflection, instanceof, and casting means that it carries some type information at runtime. C++ has typid, C# has GetType(), etc. etc. Haskell as a language has full type erasure and can be considered fully statically typed, but there are some. GHC extensions (Typeable) which point to some type information being held at runtime by the compiler.

> Actually Java has always been a fairly dynamic language. If it wasn't you wouldn't have all the XML and annotation stuff but code generation like you do in C/C++ and to some extent Go.

That's a point I never really understood. Code generation has it's downsides, but it seems vastly preferrable to the current mess of reflection: There seemed to have been a trend to move a lot of stuff that should logically occur at compile time to run time - therefore both adding a performance penalty and making debugging a royal pain - for what benefit?

There are some recent projects (e.g. Immutables and Dagger2) which seem to favour code generation over reflection again and I really hope this trend picks up steam.

> You have to remember one of the reasons why there was a shit load of declarative configuration in old Java for enterprise is because software was on premise software.

Which sounds reasonable - until you see real-world use where all components of an application are wired together with XML - even though for most of it, there is only a single setting that wouldn't break the application.

> Actually Java has always been a fairly dynamic language. If it wasn't you wouldn't have all the XML and annotation stuff but code generation like you do in C/C++ and to some extent Go.

You're equivocating on "dynamic".

Java is not a dynamically typed language.

It can be seen as "dynamic" in the sense that its behavior can be modified at runtime by external files. Then again, what languages can't?

> YAML is so much more complicated and harder to parse.

YAML has more complexity in syntax, but a data model that fits to data structures in programming languages (records/maps, arrays/lists, integers, floats, boolean, bytes, strings). As long as you do not implement a YAML parser yourself (why would you do that?) you should have easy times with YAML.

XML on the other hand is relatively easy to parse, but has a complex data model that maps well just to a DOM. For anything but markup text, you do not have a direct mapping to/from XML.

> Developers write hundreds of lines of XML all the time... its called HTML

There it makes sense, because it is marked up text you are writing and it is the right tool for the job.

> YAML has more complexity in syntax, but a data model that fits to data structures in programming languages (records/maps, arrays/lists, integers, floats, boolean, bytes, strings). As long as you do not implement a YAML parser yourself (why would you do that?) you should have easy times with YAML.

I mostly agree but YAML sounds like a serialization format and not configuration format to me.

I think a large amount programmers don't realize nor respect the history. Early Java proliferation was during the late 90s and early 2000 on-premise enterprise software. Customers required extreme customization but not all of them wanted to actually crack open and edit files.

The customers wanted to use tools and XML works great for bidirectionally editing not to mention there were shit loads of XML editing tools at the time (XML Spy).

> XML on the other hand is relatively easy to parse, but has a complex data model that maps well just to a DOM. For anything but markup text, you do not have a direct mapping to/from XML.

One of the reasons Java originally pushed XML is the support for it so good (tooling and editors). Java actually has great support for mapping XML to objects (JAXB).

Agreed up until the XML bit. It's not "XML vs YAML", it's "Why do you need all this static markup at all?".

If this is going along the lines of S-Expressions I say touche but it is what it is.

You need markup instead of code sometimes because you want declarative configuration. You want to sandbox a developer/user.

Yeah you can write declarative code in Scala (and many languages using Monads, macros or some sort of non imperative abstraction) using an embedded DSL... but it is embedded and hard to enforce someone from sticking a System.exit(1) somewhere.

Again If you are in the Lisp camp I submit there are better options.

>Kafka: is written in Scala. It doesn't use XML. Zookeeper: it was the first of its kind. It doesn't use XML.

Which is beside the point, since the parent complained about the needless complexity and layers, not just about use of XML.

>Maven: same complexity as SBT, Gradle, etc...

Which is to say: more than the task requires.

>XML: jesus will people stop the XML is complex and hard thing. YAML is so much more complicated and harder to parse. I know it is easy to read on the eyes but its harder to parse and has more edge cases.

It's not about whether it's easy to parse or not, it's about being easy to write and read when we're talking about a configuration format.

And XML in all its glory is hardly easy to parse, except if you mean by using a ready-made existing parser. In which case, everything is easy to parse (and most things, easier than XML to extract values from).

>XML is still one of the few languages you can parse and manipulate and preserve comments and whitespace.

Why would I care for "preserving comments and whitespace" in a configuration format? Except if I was doing something needlessly complex, like generating configuration on the fly on top of user edited configuration.

Which, the doing needlessly complex stuff, is what the parent complained about.

>The XML thing is the dumbest thing. Developers write hundreds of lines of XML all the time... its called HTML (pedantically HTML5 is even more complicated since it allows SGML and XML style).

Unless those developers are web developers, and especially front-end web developers, no, they don't.

And even if they did, it's one thing to write HTML in its intended domain, and totally another to have to write it (or specifically XML) for configuration.

In all, these sound more like "it's always been done that way" and Stockholm Syndrome than actual convincing arguments.

I'm curious... what do you propose instead of XML for configuration. You know that is standard and everybody knows it. Remember Java was/is very good at parsing XML.

> In all, these sound more like "it's always been done that way" and Stockholm Syndrome than actual convincing arguments.

And yeah it is Stockholm Syndrome because shit hasn't gotten that much better. Editing massive YAML or JSON files isn't really any easier IMO. You can't even put a comment in a JSON file and unless you are using Emacs I think even S-Expressions are not easier.

> It's not about whether it's easy to parse or not, it's about being easy to write and read when we're talking about a configuration format. And XML in all its glory is hardly easy to parse, except if you mean by using a ready-made existing parser.

Except XML is extremely standardized and well established and yeah there are parsers in almost every language. JSON has changed its standard a ton of times. It actually is really hard to parse correctly [1].

> (and most things, easier than XML to extract values from)

XML has XPath and XQuery. Both very well defined and have backing standards. ie not a random github project just supporting one language which is the case for JSON path. IMO XML is one of the easiest formats to extract data from. Even CSV is scary to parse correctly.

>Why would I care for "preserving comments and whitespace" in a configuration format? Except if I was doing something needlessly complex, like generating configuration on the fly on top of user edited configuration. Which, the doing needlessly complex stuff, is what the parent complained about.

It isn't needlessly complex if there are requirements for such. Maven was designed to be declarative and the hope was it could be imported by IDEs which it successfully achieved.

You know one of the reasons why Rails and various other easy to use frameworks came about is you don't need as much complexity if it is a hosted model. You don't need massive configuration if you are hosting and not delivering on premise software. So circa mid 2000 was the Rails crowd trashing the enterprise Java and probably deservedly sow.

However things are shifting back towards needing complex requirements because people want their cloud stuff to have elasticity, reliability, failover, etc (aka zookeeper) and that shit requires complexity.

People complain about the complexity of Java but I honestly think modern frontend web development is so awful today that I would take even old shitty j2ee over it almost any day (well maybe not that far but close to it).

[1]: http://seriot.ch/parsing_json.php

> YAML is so much more complicated and harder to parse.

That's only true if you stray far from the core. If you stay to the language agnostic parts, it's clean and readable.

> The XML thing is the dumbest thing. Developers write hundreds of lines of XML all the time... its called HTML

As if developers like HTML any better. I agree with you about XML being useful because it's easy to parse and the XML hate is overhyped, but that's not what he's saying, he's complaining about configuration hell that seems intrinsic to the Java ecosystem as compared to something like Rails which relies far more on convention than configuration. That's a cultural problem, not a language problem.

There are pros and cons to both ways (aka convention over configuration). That is hiding configuration complexity often get fixed with even more internal complexity except now it is hidden.

With hiding configuration your ramp up time decreases but your overall understanding of how the library/framework may decrease.

To offer the advantages of both requires even more complexity.

Which is actually what happened with Spring Boot. It is the Ruby on Rails of Java now and it is far more complex internally than the olden days of Spring 2.0 explicit XML.

At times I miss the old school Spring XML way. There used to be only like 4 tags (bean, property and include).