Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Java build systems are too archaic and complex at this moment. They should be purged and replaced with new simple tiny tool, compiled with GraalVM. Java could be compiled extremely fast, javac does not do any fancy optimizations, it just spews bytecode directly derived from AST. 99% of maven/gradle run is mindless abstraction overhead.


Don't. Just don't.

It's already a clusterfuck in JS land with grunt/gulp/webpack/TSC/rollup/parcel/snowpack/esbuild/rome etc, do not bring that madness to java as well.


that java madness has already happened...10 yrs ago!

maven is at the level of maturity where you don't need to even refer to it by it's version - it's just maven now (there's been two previous incarnations of maven, called maven 1 and maven 2). Then there's ANT, and there's a bunch of bespoke tools as well that i'm not too familiar with - ANT is still useful, but i would say that it plugins into the maven toolchain acceptably OK.


Yeah we had this stable period, but now get ready for Maven 4. There will be breaking changes.


> Java build systems are too archaic and complex at this moment

I feel the opposite. For 99% of use cases, a plain maven pom file works. If you need something custom, you should think hard about why the existing workflow doesn't fit you before moving on. I think maven mostly gets hate from hip developers because it uses xml, but the tool itself works fine.

I've spent ages more getting simple js apps to build correctly. It "just works" in java, and has for ages (thus archaic).


You are coming from a good place but... please god no, not another build system.

They are complicated because they do a fuckton of things. Please don't give me another proof-of-concept build system which then turns out to do 5% of what I needa and have no plugins available.

Gradle is fine, just use it. It's not the best. It's OK. If you hate it, use Maven. It's also OK. Just copy-paste some answers off stackoverflow and move on... we'll all be better off.


I sometimes contribute to a jMonkeyEngine, it is an open source game engine written in Java. This was my workflow in the past: fork > clone > added engine feature > deploy locally > added local deployment to my game's Gradle build file to test the newly added feature.

I recently found out that I can just use Github cli to clone from upstream, and add one line in my game's Gradle build file to tell Gradle to use the cloned folder instead of looking at local cache. In Gradle world it is known as Composite build and, it has really make me like Gradle despite their convoluted build files.


Maven is great as long as you buy into their philosophy of how builds ought to work - phases and actions happening at a particular phase.

If your build has really custom stuff, and you cannot fit your custom work into those phases (e.g., it interferes with some other custom stuff), then you have a maven problem that's hard to solve. One usually resolve this by writing a maven plugin, and that kinda sucks. But hey, at least if you do it, you can contribute this to the whole plugin ecosystem and thus, improve it for somebody else.


Usually the solution is to break your project into smaller modules, each of which can follow the normal lifecycle, and express your special-case requirement through module dependencies (e.g. maybe you have an integration test module).

IME the benefits of fixed phases outweigh the costs: any developer can pick up any maven project and immediately know how to build it, how to run the tests, and so on. A lot of other build systems are really bad for knowing where to start; allowing arbitrary task names and arbitrary relationships between what runs when just ends up with projects having pointless differences between what they call things - do I need to run "gradle build", "gradle install", or what? (and similarly for sbt etc.)


> If your build has really custom stuff

That's the biggest problem. Nearly every developer thinks their build has *really* custom stuff whereas it's wrong in 99% of the cases.

Then comes Gradle with its so-much-vaunted flexibility and deliver you exactly what you think you need. And who is going to maintain the clusterfuck of spaghetti code that your build has become?


Could you provide examples of better solutions for other platforms? I've been doing software dev professionally in 5+ languages for the past 20 years and speaking from experience java has one of the best build/dep management systems to choose from.


Are there other build tools for other languages that are much faster for the same codebase/complexity?


Cargo. Or just plain make.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: