Hacker News Reader

> they are building pyramids while other languages are building stuff out of bricks

Pyramids are engineering feats, Java EE people are building stuff which look like works from M. C. Escher, it bends your mind when you try to understand the code :)

Also a little anecdote to the complexity of enterprise stuff: at the company I worked before, they were writing an entire persistence framework from scratch (with annotations instead of xml) so they could get away from hibernate.

Also well known as the Enterprise Software Engineer Employment Guarantee Scheme

> they were writing an entire persistence framework from scratch (with annotations instead of xml) so they could get away from hibernate.

As opposed to using MyBatis or JDBI? What was their rationale for rolling their own, too many employees on the team?

Maven is wonderful. It's the opposite of complicated. You declare the artifactId, "groupId" and version of your project. You declare those same values for your dependencies. And then it Just Works. When you want to release, you invoke the release plugin, and it will do all the right things. If you want a test coverage analysis, you invoke a suitable plugin (e.g. emma) and it'll do the right things. It is, hands down, the best build system I have ever used, in any language.

The problem comes because everyone thinks their build is a special snowflake that absolutely needs to replace every instance of the number 15 in their codebase with a heart symbol. No. You don't do that. If you're doing something standard there will be a plugin for it. If there isn't, it's probably because what you want to do is a very bad idea - do it in code instead. If you absolutely insist, you're going to have to write a plugin, which at least means you'll follow coding standards, have test coverage, and all the rest of it, rather than just sticking random unreviewed crap into your build like happens in every other build system.

> Maven is a nightmare to use, it's so complicated I would generally not use it. I would just like a package manager which is only doing packages like any other language.

Before Maven, generally I remember there being Ant. And I remember that if an application needed dependencies, unless one explicitly used a dependency manager like ivy, one had to go find the jars and download them, and ensure they were on the class path. Ant was simpler, in the sense that if you wanted something to happen, you would create an ant target and instruct ant on what was going to happen.

Maven isn't simple in the same way, so it does require one to learn more about how it works in order for things to fit together, but I find it drastically simplifies working with java projects. The location of all dependencies are defined, they are downloaded, and there is default behaviour to be expected with each of the maven goals. Overridable properties enable one to have a build which works first time directly after checkout. I much prefer it to what was there before.

If we look at what has come since - sbt, gradle, and leiningen all seem to use a similar mechanism to Maven for dependencies.

sbt, gradle, and leiningen each bring a better syntax to build scripts, viz their respective programming languages. They each pitch the ability to drop out of their declarative syntax when needed, but from the samples I've seen of gradle and leiningen use in open source projects this facility is rarely used. I guess it's because replacing procedural build code with declarative was the reason projects bought into Ant and Maven in the first place. In my opinion Gradle would do well to replace its Groovy DSL with its own lightweight one with a similar DSL and let developers use Java lambdas to do any procedural customization if it's ever required, just like they removed virtually every line of Groovy from their codebase for Gradle 2.0.

> Maven is a nightmare to use, it's so complicated I would generally not use it.

The maven ecosystem is really nice compared to that of many other languages (e.g. python, javascript.) It's deep in terms of functionality, but for getting started (dependencies) it's not that complex. And a good IDE will take care of all of the boilerplate for you.

> Nothing works by default, you always have to include stuff here and there, write one or two xml files before anything would work,

I do share your dislike of enterprise Java development on the other hand. I worked a JBoss/Spring/Hibernate/Tomcat contract a while back; that thing was an unholy mess which took 4 minutes(!) to start up. However, there are much lighterweight frameworks out there; I'm currently building an app on angular -> dropwizard/guice/jdbi, which overall is quite elegant. No XML in sight (aside from the maven configs).

I also tried some JEE in ~2000 and hated it. How could one accept to code in such a bloated ecosystem?

I'll admit I filtered out a lot of candidates becaused they mentioned stuff like "J2EE Engineer" on their resume, which seemed to imply strong incompatibilities with our coding style...

Fortunately not everyone in the Java community is modeled after JEE (or Maven, Spring, etc.).

Right now I work for a large European bank with Java EE and Wicket. I only touch an xml every 2 months or so. I'm not saying it's better than RoR for example in this regard, but Java EE has come a long way since people here used it, and even if it's still not your cup of tea, you should check out Play framework. I've had personal projects in .NET and I can say that there is a lot more boilerplate and spaghetti code there.

Maven archetypes make Maven a lot easier to use, and the standardization of things such as JPA and CDI and the simplification of EJB has gone to lengths to reduce the complexity if JEE. That being said, this isn't a "Hello, World" app, but more of using "Hello World" to demonstrate how to set up the full JEE system.

Maven is awful but the community has adapted and now we have good build tools like gradle.