[rb2k_]

I always had the impression that people that say they 'hate Java', usually don't hate "Java: the language". Most people that dislike programming in Java have a negative sentiment because of:

- the usage of XML (or now: annotations) to configure all of the tiny parameters that nobody really cares about

- a class hierarchy in which you have to jump to 20 levels of inheritance to get to where you want to go

- that a lot of Java developers aren't able to compile their application outside of Eclipse

- that people build in "flexibility" in form of factory methods but at the same time only have the factory only build the same thing over and over again

- that setting up java projects is usually an unpleasant experience with way to much work if you only want the basic functionality because there are no sane defaults

- that there is no proper package management for libraries (similar to something like 'gems' in Ruby)

- that all of the concepts that the language is missing was 'patched' in using reflection, injection and annotations

- that the language just seems stuck (for how long did the Java community talk about Lambdas by now?)

- that most Java libraries don't seem to be able to provide a simple example (compare to ruby, examples on the front page: nokogiri.org, sinatrarb.com)

[gizzlon]

Absolutely! I don't particularly like Java the language, but what I hate is the bs-filled "enterprise" ecosystem where code and technology is just an afterthought. Things may have changed though, but 4 years ago I had to look up Java projects on Wikipedia to understand what they where.

[ralfn]

You hit most points. Lets add one of my personal biggest gripes:

- Java reperesents a way of thinking where all languages issues are fixed in the IDE. A thinking which enables the language itself to grow in all the wrong directions.

Its not so much that that is always a bad thing. But if the usability of a language is so dependend upon and designed for an IDE, that IDE really should be part of the language design.

[altcognito]

I agree with all of this -- Maven has fixed the issue with package management to some extent.

[rb2k_]

Using maven was a horrible experience for me every single time :(

It seemed to download the whole internet and POM files are using everybody's favorite configuration language: XML

[lmm]

It is, but it uses XML right: for a declarative document, and one that has tools for editing rather than having to do it by hand. Maven is glorious because it ensures your builds are actually reproducible, something which I've never seen any other language or build tool accomplish.

[ollysb]

For a number of reasons Bundler/rubgems does a far better job of reproducible builds.

1) Maven doesn't generate an equivalent of Bundler's lock file. It resolves the versions to be used on each build. If you have dependencies on snapshot versions then there's no way to ensure that all developers are using the same snapshot. OK, you can always specify versions explicitly, but then you lose the benefits of snapshots etc. Bundler's lock file allows you to easily check for newer versions(a gem at a time if you like) without losing reproducible builds.

2) Developers can't upload their jars to the central maven repository. There are gatekeepers. This means that the latest versions of many projects aren't in the central repository. For those projects you have to use their own specific repository. This leads to problem 3. With rubygems developers can upload gems straight into rubygems.org. Also, because most projects are in github and you can specify git dependencies with Bundler you're able to depend on any version of a project(regardless of whether or not it's been released to rubygems.org), all the way down to the commit level.

3) 3rd party repositories change and can be unreliable. This means a jar can become unavailable without any notice. In practice the only way to guard against this is to use a proxy repository like nexus or artifactory, yay, another server to maintain...

[lmm]

1) The whole value of depending on snapshots is letting each developer run everything against their local, possibly-modified versions; there would be no point forcing snapshot builds to be reproducible. Release builds aren't allowed to depend on snapshots. Maybe I'm just too used to maven, but I don't see how you'd do it any other way.

2) Gatekeepers have their advantages; how you run a repository is pretty independent of the build tool. It would be possible to start a "anyone can upload anything" maven repository if this was thought useful.

3) Surely the notion of having your build depend on a random third-party git repository is far more worrying than depending on a random third-party maven repository - wouldn't you need to set up a git mirror server, which is more effort than nexus or artifactory?

[ollysb]

First of all, let me say I'm not a maven hater. If I was working on a java project I'd use it.

1) The problem is that until you lock down the dependencies you can never be sure exactly which versions will be used. When you use bundler it generates a file specifying all of the versions that should be used. This gets checked into your repository so everyone is sharing exactly the same versions. This means you don't get situations where you check some code in and you break the build because the build server has downloaded a newer version of a dependency(used to happen a lot for me).

2) It's true it would be possible to start a "anyone can upload anything" repository. Having seen how well rubygems.org works in this scenario I think the java community should really get one organised. Either by enhancing the central maven repository or replacing it entirely(it's always been damn slow to browse anyway).

3) In my experience Github projects tend to be pretty persistent, if you have any concerns though you can always hit the fork button and depend on that. Having said that, using git dependencies is definitely the plan B option.

[batto]

What a non-sense. You can't sanely describe build of your project(s) in documents. Did Maven folks include every possible scenario in markup? Nope. And that's why all Maven builds that are not simple jar of classes tends to have long sequentional calls of build plugins.

I see it this way:

First we had bash and make and ability to do almost everything (run other programs, ...) by using the right thing/language for the job. There was only lack of the functions to deal with Java builds and package management.

Then we had Ant, XML programming language with very limited possibilites (I don't regard targets as a feature). But at least we could express what we wanted.

Then we had Maven. If we needed something special we need to add it to sequence of build plugins (in several hardcoded build phases). Mostly we resort to do things in Ant plugin.

This is why I hate Java. Because of such idiocy.

[lmm]

The ability to call random external programs during the build of your project is not a feature, it's a bug. Likewise the ability to lay out your source arbitrarily. Your project's build is not a unique and special snowflake; it can build the same way as every other project, the way that has already been tried and tested by millions, the way that any developer will immediately understand.

If there's really some step that needs to be done in your builds that isn't covered by the existing plugins, you can write your own (it's not hard) and then at least that step is happening in a structured, testable way. But if you're doing something unique to a single project, you shouldn't be doing it in the build system.

[pnathan]

> Your project's build is not a unique and special snowflake; it can build the same way as every other project, the way that has already been tried and tested by millions, the way that any developer will immediately understand.

No, actually, builds can get very unique in multi-language systems or in embedded systems... believe me. =)

[tomjen3]

You have not seen our source code.

Anyway ant is for builds, Maven is for dependencies.

[st3fan]

"Did Maven folks include every possible scenario in markup?"

For me the main point of Maven is that you keep things simple and standard. By not deviating from a standard Maven web project structure and avoiding dependencies or build phases that need special care, I have projects that are simple to develop, build and package.

I am trying very hard to just depend on good behaving Maven dependencies and to stick to simple solutions. No more special build phases for code generation, no more crazy stuff. If I need some special build phase then I am probably doing it wrong.

The result of that is also that my projects are super simple. By avoiding special build phases I can pretty much load up a project in any IDE and just hit Run.

To me that is the true power of Maven. For that reason I don't want to look back at Ant or any of the fancy super flexible Groovy/Scala/Ruby build tools.

So contrary what many people think, Maven forces you to keep things simple. And I think that is a good thing in any project :)

[equalarrow]

'So contrary what many people think, Maven forces you to keep things simple.'

This is absolutely why I left Java development. Maven in my mind is anything but simple. It was always frustrating to use - this was 2.0 mind you, so maybe things have become easier, but I doubt it.

Even the terminology is totally abstract and complicated. I built a big project for a well known bank around '05-'06 and we had all kinds of problems with maven - we just went back to ant.

I used to love Java in the late 90's/early 00's. I remember the resistance to doing projects with it - it was new, unproven, etc, etc - just like Language X today. I worked with some people who built some cool things with 1.2. The collections framework was great.

But, then all the enterprise stuff started creeping in and everything was configured with gobs of crap xml. Demos would be given where you could edit the configuration via gui tools, but none of the devs I knew did this. Everyone hand edited everything.

Things like maven with their overly abstracted naming and concepts and Spring where everything is 'wired up' by tons of xml are what ultimately drove me away from Java. I just wanted to spend my time working on features instead of configuring things.

[batto]

> So contrary what many people think, Maven forces you to keep things simple. And I think that is a good thing in any project :)

Forcing you to something is anything but good.

[zaptheimpaler]

I haven't worked in the industry for very long. Could someone explain why build processes tend to get so complicated? I have some intuition about the steps that a build process takes being complicated, but it seems to me that the process itself would be linear i.e

A + Config -> B -> C -> D -> E -> Compiled

Maybe you could have decision points in the compilation flow depending on config parameters, system parameters, making it a tree, but I don't see why a build tool couldn't make those decisions based on the configuration provided. Essentially, I envision a build tool that takes in a huge number of arguments (maybe reads them from an XML/JSON/whatever config file) with sane sets of defaults for each.

(Forgive me if all this seems naive, it most likely is. I want to know why.)

[lmm]

>Essentially, I envision a build tool that takes in a huge number of arguments (maybe reads them from an XML/JSON/whatever config file) with sane sets of defaults for each.

That's pretty much how maven works. A typical java project will have an xml file listing its name and version, the names and versions of all its dependencies, a scm URL for tagging releases and that's basically it. The problem is people who have got used to having all the freedom of calling arbitrary shell programs at any point in the build process; it's very easy to accrete a series of small hacks ("oh I'll just sed this file here to fix that") that add up to something incomprehensible.

[rb2k_]

In Ruby:

To make sure I have the right version of my libraries I use bundler

To make sure I have the right version of my code I use git

To make sure I have the right version of other applications I use chef.

Has worked fine for me so far...

I guess it's the usual unix philosophy where each tool does a single job and does it well.

[markokocic]

So basically one can replace one tool in Java (maven) with four different tools with different conventions and usage scenarios and call the Ruby way simple, and Java way too complicated?

[batto]

It's better to use different good tools, rather than one bad tool. And by the way, since when is Maven SCM? AFAIK Maven just pollutes SCM with it's dumb release plugin.

[ZitchDog]

(maven only solves one of those problems)

[edwinnathaniel]

Some libraries that are being stored at Maven Repository have 2 additional artifacts: source-jar and javadoc-jar.

If you're using Eclipse and Maven plugin, the beauty is that when you hit a shortcut key to navigate to either the Definition or the Implementation of 3rd-party open source library, the Maven plugin will download the source code for you and voila, no configuration or anything like that needs to be done with Eclipse (telling Eclipse where the path, etc).

It's powerful.

[davedx]

Same. Maven drove me pretty crazy, to be honest. Compare it with Ruby gems or Laravel's bundles, Maven felt like using a ten thousand ton tank to round up sheep.

[st3fan]

"It seemed to download the whole internet"

It just grabs your project's dependencies and probably some extra stuff the first time you use maven.

This is not really different from python or ruby build systems.

[nahname]

XML and the language are my biggest gripes. Checked exceptions are a bad idea. Lack of lambda expression (though they are coming!) is pretty much a deal closer. After many years of working on code, the only real way to clean things up is often a lambda. Turn 120 lines into 30 over 4 files? No chance in hell you were using a Factory Method pattern to do that.

[silverlake]

Among mainstream languages Java is still a good choice. It's easier than C++ and more portable than C#. If you want a dynamic language, you can write chunks of your system in Groovy or Clojure. If you want a strongly typed language with smart features, use Scala. If the build system and frameworks are too big, there's space for someone to design something simpler. There's not much inherent in Java the language that prevents this. The lack of closures is irritating though.

[myspy]

- Programs build in Java are usually pretty ugly. I don't know if this can done any better, but I don't like using Java programs.