Point #2 isn't very strong. Every language has good support for both technologies these days.
Point #3 is absurd. If you know JS and you know HTML, you're not far from the basics of XML. If you're contemplating JSON as a replacement, you're either assuming our poor web developer is really stupid or you're comparing apples to oranges.
In general, your argument here is that JSON is shorter and more popular. Sure. But unless your top concern is bandwidth (hey, maybe it is) there might exist other technical reasons to make the choice which are less childish.
2. Maven is a nightmare too. Every time I've used it (usually because I'm compiling someone else's code and they wrote the build in maven), it downloads hundreds of megabytes of who-knows-what from random Internet sites. I want to pin versions of dependencies (and dependencies-of-dependencies) so my builds are repeatable, and I want to be sure everyone who's forked my git repo can still build the code if the Maven URL's for the deps have gone out of business. I recall trying to read the Maven manual, but both the manual and the concepts were incomprehensible -- there's so much automagic, when things break, it's difficult to even come up with a hypothesis of what might be going wrong. (And anyone who has any experience with any build system knows that the build always breaks.)
I usually just use Ant. It's a bit of a pain shuttling jar's around (symlinks help), but at least I can understand the build.
3. Part of the problem is that I don't want this alphabet soup of technologies. If I'm running in Python, and I'm developing a prototype or a one-off hack, I just write a file called whatever.py. (I can "import json" in whatever.py if I don't want to use hacks like eval()/repr() or copy-and-paste for parsing/serializing.)
I want to be able to build a quick one-file prototype to process my XML, without enabling the "Java EE 6 web profile" (whatever that is) and writing a Maven build file. I want using XML to be this simple:
sudo apt-get install default-jdk
javac Whatever.java && java Whatever
2. You may not like Maven--I hate it too--but it's how things are done. In practice the only people complaining about installing libraries and managing jar dependencies are people using ant without ivy. 90% of folks just use Maven and get on with it.
3. You're turning your complaint from "Java's XML support is weak" to "Java's XML support isn't Pythonic like Python's." This is a weak argument. You're saying you want to live the Python dream in Javaland. Well, it isn't going to happen, no matter what the Play guys tell you. But if you have to use Java--and sometimes you do--adding four lines to your maven config--which you will have--so you can use EE 6 or JAXB is not a big deal, and neither is putting a few annotations on a class.
I don't love Java. In fact I dislike it. I would rather be using Haskell, Python, or Ruby. Or any number of other things. But you can't be mad at Java for being Java and not Python.
That's by default in maven - you have to do something really stupid to get non-repeatable builds (usually involves specifying open version ranges or some weird plugin magic)
>everyone who's forked my git repo can still build the code if the Maven URL's for the deps have gone out of business
One of the main advantages of maven is just the opposite of that - you don't have to bundle your dependencies and get them to other people - they can just ask maven to fetch them. And maven is not going away.
I think they changed it now but for years the default behaviour was to get the latest versions of every plugin, making builds non-repeatable by default.
This got me up to speed pretty quickly to learn JAX-RS providing XML and JSON.
<http://androidexample.com/Camera_Photo_Capture_And_Show_Capt...
Java integrates everything you need to parse and generate XML. Most API are XSD driven (either through annotation in the code, or with the mapping code generated from the XSD), so you get plenty of types like data, int, ... You also get streaming parser (pull or push) and DOM.
Obviously, that is no longer plain XML, that is XML + XSD + Namespaces.
The J2SE (not JEE) also has built-in support to expose and consume webservices, without requiring to worrying about WSDL and the rest.
At the end of the day, that does not mean that dealing with XML is a great experience. Most real life XML is awful. And well although the basic tooling is there, that is in the usual java fashion with factories of factory of creator of generator and very little "high level" utility.
In XML this has to be
Of course, I don't know what you're talking about "JSON doesn't even have a bloody date or time type" when XML doesn't have anything but strings. In order to parse this, I'd have to have code which looks for <int> tags and runs my language's atoi() on the content.Maybe there are libraries that do this automatically. If there are, the XML community does an excellent job of hiding them from developers; I've worked a fair bit with XML, and haven't found them.
2. Easy interface with popular languages. You can just copy-paste a JSON string into a Javascript / Python app. (Warning: If you do this programmatically, it's going to be a security vulnerability.) Whereas if you want to use XML, you have to jump through a lot of hoops. Especially with Java; AFAIK the Java standard lib only ships a specification for XML parsing. So while the org.w3c.xml namespace is there (or whatever it's called, it's been a while), you have to install some Apache lib called Xerces or Xalan or Xavier (or whatever it's called, it's been a while) in order to have XML support.
This is Java's fault, not XML's; but XML was a shiny cool thing at about the same time Java was, so a lot of peoples' main XML experience (or at least mine) is in Java.
3. Is a subset of many popular languages. A lot of people -- especially web developers -- only know one language. If you know JS, then you know JSON. But XML syntax and semantics is very different from most programming languages, and that's a barrier. (General XML is much different than HTML. In particular, you can always see what HTML "does" by loading it in the browser because everything has default styles; not so with a general XML format, unless you go through the pain of writing a complete style yourself.)