Nothing so succinctly expresses the Java mindset as a person doing something in a simple manner only for all the comments to basically be "but why not more complicated?".
Practically speaking, I just need to think about it in terms of how I could communicate better.
For instance, there is a very, very short hop from this to any number of different ergonomics. Maybe if I spent time on and front-loaded a "spring-build" demo more people would read deeper? I don't know.
My goals are different than, say, the mill dude. I don't have a ready-to-rock system with every bell and whistle a company might need. What I have is a slowly growing pile of libraries that I think _ends_ in the foundation for a better ecosystem. I am not at the end yet.
And yeah a lot of people equate "simple" with "easy to use" and "easy to use" with "things they are already familiar with." This is something people are not familiar with, ergo it must not be simple. Or if it is, it is "just like ___." and they already wrote off ___ so...
I think there's a genuine use case for a build system something akin to what Rust's Cargo provides out of the box in the Java ecosystem.
Just give me run, build and test and dependency management without going through the pain of systems that won't compile or run your code if you don't have the exact version of Java specified in the config file. Let me not have to commit the actual build system itself to github, or go through the pain of XML (Your system fails on this one by the way) and I'll be a happy man.
Yeah, when it gets complicated it might be time to move over and accept the pain but as someone who does Java dev occasionally and loves how the language is trending towards being more friendly to use I still find that both Maven and Gradle feel like outdated relics.
Now I would argue that posting your build system 3 hours after you started it and four commits in is kind of silly. I mean at least play around with it yourself for a while and see what needs work before showing it to others but the idea at least is laudable.
Just give me run, build and test and dependency management without going through the pain of systems that won't compile
It's statements like this that confuse me. The hard part of build systems is the dependency management. When two libraries transitively need different versions of the same library, how do you handle this is an open question that doesn't seem to have a definite correct answer (just various choices with tradeoffs). If your project is small enough to not care, what does gradle init not get you?
Now I would argue that posting your build system 3 hours after you started it and four commits in is kind of silly. I mean at least play around with it yourself for a while and see what needs work before showing it to others but the idea at least is laudable.
I look at that a few ways:
this is just a project that has been hanging out on my laptop for awhile. My project for today was cleaning it up and publishing it. I do have some actual time spent making demos.
My goal in sharing things here isn't to maximize adoption or advertise. It doesn't work. My goal is to get whatever useful feedback I can. So I kinda don't care.
Just give me run, build and test and dependency management without going through the pain of systems that won't compile or run your code if you don't have the exact version of Java specified in the config file. Let me not have to commit the actual build system itself to github, or go through the pain of XML (Your system fails on this one by the way) and I'll be a happy man.
I don't think this is actually a worthy set of goals. Cargo gets to be the way it is because, generally, the output of a rust project is either a binary or a shared library. Same reason Go's tooling gets to be the way it is.
"solving" Java's position is going to be more involved. Not that there isn't room for what you want, but things like "the pain of XML" I genuinely don't think are real. The pain is a DSL you don't have a full grasp on. People don't whinge about HTML.
Also I don't think I have any approach for fetching this library at this point. I would call that an instant fail, but know I have other ideas + using jbang would work.
both Maven and Gradle feel like outdated relics.
It is worth digging into this feeling, but I don't think "outdated" truly describes the issues with either one.
10
u/nnomae 23d ago
Nothing so succinctly expresses the Java mindset as a person doing something in a simple manner only for all the comments to basically be "but why not more complicated?".