Hacker News Reader

Comment by geofft | Hacker News Reader

I'm curious, what parts of the Java ecosystem (other than simple stuff, or old stuff, or non-Java languages on the JVM) don't involve thickets of XML tags? I have so little Java experience that it's fallen off my résumé, so I'm sure I'm uninformed and would like to be more informed. But everything I've seen of actual, production Java development today heavily uses XML somehow, from Ant or Maven build files, to web.xml, to Spring dependency injection, to Android, to even Java Web Start.

Is there any serious part of the Java (Java, not Scala or Clojure) ecosystem that doesn't involve XML at every corner?

View on HN

Well, for starters, Spring basically has eliminated XML configuration with Spring-Boot. Add a couple annotations and you're done (as in, fully done, no web.xml's, no application-contexts). (Granted, I don't really like this, from an engineering point of view, but whatever).

Also, I really wouldn't complain about Maven, as it is hands down the best dependency manager available from any language, bar maybe gem/rails (node isn't even close, since you need a c++ compiler to actually get quite a few packages). There are also enough plugins for every IDE out there to handle Maven POM's.

But if that wasn't enough, there's now Gradle. You can literally have an entire Spring/Java/Grade project that doesn't use ANY XML, but purely Annotations/DSLs.

Secondly, there's a major selection bias at play. In your own words "everything I've seen of...", sorry but your point was lost right there.

Yes. I've seen (and written) plenty of actual production Java code that doesn't use any XML configuration at all.

There are a lot of issues with Java, but XML isn't INHERENT to it.

Annotations are IMHO just another and admittedly shorter representation of the same problem.

You still have to learn them by heart for each lib, you don't know when they are executed and you cannot reason about them (as you could with source code).

Pretty much the same problems as XML if you ask me.

If by the same problem you mean that you have to understand a library in order to use it properly, I guess so, but I don't see how that's unique to Java.

I don't see any difference between having to understand annotations and having to understand libstdc++ for example, or having to learn about any particular ruby gem or node package.

Every language has to deal with configuration files. Complaining because a bunch of Java developers used XML in their projects seems trite.

I think XML actually has a lot of strengths (having well-defined-types and structure for one). If the complaint is that it's worse than JSON, well...I've seen way worse than XML (ASN.1 for instance), so idk...

I'd put XML and annotations in the same class of problem because they are (mostly) not checked by the type system. For instance, you can have a REST controller that simply does not "work" because you're missing an annotation. You can easily debug this if is a place in your code where the controllers are registered, but with annotations the interactions between your code and the framework (or whatever requires annotation) are not obvious by just looking at the code.

Not really. Annotations are included with the code, unlike XML. They are much easier to reason about due to the immediate proximity. How do you feel about Python decorators? It's the same thing.

> as it is hands down the best dependency manager available from any language

Why? You don't back that statement up with anything. What makes it better than `pip`?

> node isn't even close, since you need a c++ compiler to actually get quite a few packages

Well if the packages contain C/C++ modules and don't distribute binaries... (which a lot do). In Python land packages with a C++ module normally have a pure-python fallback anyway.

Recently moving from Python to Java. `pip` doesn't even come close to Maven. Dependency management used to be something I needed to manage much more closely in Python. With Maven, it just works.

I'm just curious as to why. You specify a list of requirements and their versions, and those get pulled down from somewhere and installed locally. What makes Mavens process far superior to pip (or npm, or any other program)?

Because with JVM languages, and their "horrid" backwards compatibility (that everyone always loves to bash), I can declare dependencies on libraries written in Java 1.1, and it will JUST WORK.

From what I understand, there's a fairly large chasm between Python 2/3 (such that a lot of people use external libraries to deal with coding cross-compatibile code, and apparently get wrong some-times).

> In Python land packages with a C++ module normally have a pure-python fallback anyway.

Completely not true in my experience. Running pip install and finding out a dependency is native code is the worst feeling, because now I need to replicate a dev environment for building the damn thing, on windows I don't even bother, on linux I'm left hunting down the right linux packages, which if someone bothered to specify was only specified for one of the distros.

> Why? You don't back that statement up with anything. What makes it better than `pip`?

I'm not super familiar with the python ecosystem, but my biggest gripe is above (randomly, dependencies will fail to install). My second gripe with python is that so many things need virtualenv.

In this regard I've had a lot less pain with npm (but I've also done far fewer things in node), and I've never had an issue using a library in the java ecosystem, I just plug the appropriate deps into my build system, and it works, no installation required.

Beyond "can I use the packages easily", Maven also supports artifactory so that we can have org-wide libraries rather than needing to rely on git to avoid duplicating files everywhere. Beyond that Maven is also the Grunt of the Java world; it compiles your code, it invokes JUnit, it runs your fancy code rewriting modules, it does your jar/war packaging, and runs all the other modules you want.

Maven has it's own issues sometimes, but having too much XML is so far down the list of things I care about, but Gradle is nice too and the syntax is much more terse and I try to use it for my own non-work projects.

In contrast to the general "install a pile of things not in your dependency manager" approach of pip/npm, I just setup a java project to use webkit (with no prior experience trying to do this in java at all) in 5 minutes by adding 2 entries to a pom.xml file as described on https://github.com/ui4j/ui4j/

Well, I don't have that much experience with Python, but by your own admission:

   packages with a C++ module normally...

Sorry, but 'normally' doesn't cut it for me (or the organizations that I work/worked for).

I can use ANY maven dependency, regardless of what JVM language it was built with, what language level (java 1.1 - 1.8) it was built with, pretty much anything.

Thanks for the reply, good to know! I hadn't heard of Spring Boot and had forgotten about Gradle.

In case I wasn't clear - I wasn't trying to have any sort of "point," merely asking for the sake of learning what the Java world looks like. I think my experience with Java is pretty average for a non-Java developer, though (I took one class in college, and worked a few years on the client side at an enterprise software startup, where the server was J2EE, and had no particular influence on what stacks were used in both contexts). I certainly am not complaining about Maven, just relating the fact that it involves lots of XML.

I totally get that XML is intimidating, it certainly was for me for a long time, but eh...it solves more problems than it creates (at least in my professional opinion).

But... I'll be the first to admit that Java isn't the perfect tool for every problem, and I certainly feel that as engineers, we should use the proper tool to solve the problem.

I've been using Dropwizard extensively at work for the last 8 months without touching XML.

I'm really enjoying Dropwizard. It has helped pull me back in to the Java ecosystem.

I do Java projects for more than 15 years. I know the times when XML-based configuration was the standard. Now, I am working on the MVP of my startup, with Dropwizard. The XML days feel like stories from a fairy tale.

But I have to say that XML is often blamed by people who think that complexity would magically vanish. Complexity does not vanish. It can only be shifted around. And it often requires lots of iterations to find an approach that is good enough for everyone. Back in the days, if tooling was right, I did not care about the amount of XML.

As a Java developer doing mostly enterprisey stuff, I haven't used XML in years. Yes, web.xml is maybe the only piece of XML I have to deal with in certain cases.

Lots of Java packages don't use XML. Just on the web app servers: Play, Vertx, Spring MVC, Dropwizard, and others don't use XML. The new crop of micro framework stirred clear of XML: Spark Framework, Pippo, Rapidoid, Blade, and Jodd.

I hate Java.

There is ONE exception, when I decided to mod the game Starsector, setting up the project, and compiling and running while using IntelliJ is far easier than any other Java project I ever had, also no XML anywhere, it so wonderful it ALMOST made me like Java.

Spring Boot is very serious.

Ever look at an eclipse project file?

Barf

I'm a java developer. Why should I look at a eclipse project file? (Ok, as I'm using Idea - why look at an Idea project file?) Those are the internal storage systems of the IDE and I don't care what they use. And I won't go around patching the IDE's config files manually ever.

Why because the project you need to swipe some stuff from has no build system other than the wretched eclipse project file. Put it this why, you look at the project file, it's a tell how horrid everything is with the Java ecosystem that someone thinks that is a good idea.

Reply on news.ycombinator.com