Maven isn't Java.

I've used java for over 20 years and managed to almost completely avoid it.

As with npm - I think automatic dependency management at the library level pulls in far too much of the world - most of which your code doesn't actually depend on because the one function you need in lib A, doesn't actually require lib B, and therefore lib B dependencies C&D etc etc etc.

Madness.

If you do dependency management at the source level ( using the compiler.... ) then life is generally much simpler ( reflection being the only aspect you need to manage ).

Could you elaborate on what you mean by "dependency management at the source level"? Do you mean manual JAR inclusions into the project?

The key thing to remember is the transitive nightmare of dependencies that you let Maven manage is largely created by the way Maven works!

So if you don't do it that way, just you need to manage the dependencies yourself, but they are much much simplier!

In a bit more detail - at the top of your source code is:

import someorg.somepackge.class;

If you have the source code for someorg.somepackage in your sourcepath/classpath ( and the source of any transitive dependencies ) then the compiler will magically find all the transitive dependencies for class at the class level at compile time. [1]

This results in the minimal number of classes you have to ship and as a result the minimal number of transitive dependencies.

Now your build tool/script ( whatever tool you use ) will need to bring in those dependencies from a versions repo somewhere - but that can be your own source code repo ( vendoring I think it's called ).

Yes - you need need to keep that build config yourself - but frankly that's time well spent as it results in you have proper control over your dependencies, and they don't balloon out of control.

Occasions like some random third party has added dependency D to C which is brought in via an A->B->C chain and then you have some library version clash are much much less as a result.

That's not to say I don't occasionally use jar files in the classpath - but that's typically only if that library is self contained, single focus and small - and again you can put that in your build script.

In my view, Maven magic is part of the problem, not a solution - and to sum up why - it hides the cost of the dependencies - if people had to manually add the chain of true dependencies when they decided to use a apache utility class, they might think twice about whether that chain of dependencies is well designed or not.

[1] With the reflection proviso I mentioned above.

> Maven isn't Java.

The wheels aren't the car. Sure, try to drive around without wheels.

In my experience using Maven is like driving around with a set of powerful magnets tied to the back with string.

You gradually pull in more and more c*p.

I've used Java since it came out and I have never used Maven

"..and the amount of effort needed to produce a single binary."

A couple of minutes ? Even timed this with another HN Java disbeliever who said its too much effort.

I understand that you mastered producing a single binary with your favorite build tool. In my experience if a language does not have an official way to build projects it does end well. Go, Rust and Zig are the prime example that a language should not be separated from its build system.

How to produce a single binary:

    go build


    cargo build


    zig build


  <project>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-shade-plugin</artifactId>
        <version>3.4.1</version>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>shade</goal>
            </goals>
            <configuration>
              <artifactSet>
                <excludes>
                  <exclude>classworlds:classworlds</exclude>
                  <exclude>junit:junit</exclude>
                  <exclude>jmock:*</exclude>
                  <exclude>*:xml-apis</exclude>
                  <exclude>org.apache.maven:lib:tests</exclude>
                  <exclude>log4j:log4j:jar:</exclude>
                </excludes>
              </artifactSet>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
  ...
  </project>

Can you spot the difference?

I would like to point out that the language compiler in Rust (rustc) is certainly separated from its modular build system (cargo).

Also, how so wonderfully and utterly balanced of you to give an old-school Maven pom.xml file with the maven-shade-plugin and exclusion lists, but omit the Cargo.toml and go.mod files.

Also, its as simple in Java as:

Gradlefile:

  apply plugin: 'java'

command:

  gradle build 

Can you spot the difference ?

EDIT: Ok you were asking about creating single all-in-one fatjar ? Add the below to your Gradlefile:

Gradlefile:

   plugins {
     id 'com.github.johnrengelman.shadow' version '8.1.1'
   }
   apply plugin: 'com.github.johnrengelman.shadow'

command:

   gradle shadowJar

> utterly balanced of you to give an old-school Maven pom.xml Sorry I started to use Java a long time ago, not sure what is the "recommended" way of doing things today.

I guess I just need to know which random Github project is the new hotness today that does something that the other languages do out of the box. Thanks for supporting my point of view.

Again, to produce a single binary you need to know/care much less with Zig, Go and Rust than with Java.

Yes, one is a command line command, the other is a part of a build description file, so false equivalents.

Is this a joke? Or you didn't really get the simple point that build description file is not mandatory or even required for other mentioned languages.

But dependencies are somehow needed for Java (otherwise, what are you excluding? Log4j is not there by default)? How is that a fair comparison?