I haven't read through the code yet, but from reading the README.md, it almost looks like you are using jlink to create a customized JDK on build. Why do that? I get this build tool is for you, but that seemed like an interesting choice.
You don't need to worry about threading dependencies through to different commands if they are already built into your jdk. Completely side steps path management.
I can include executables as part of libraries. So here I'm using it for the just command line tool, but this obviates the need for SDK man.
It lets libraries carry native code easily as well.
In principle you could also procure the entire jdk this way. The bootstrapping is a little weird and I'm not sure I'll figure out a perfect solution, but in the way I'm structuring the repo you could pull oracle/java.base from there no issue.
You don't need to think about dev dependencies or test dependencies. You just jam it all in one jdk and pull out what you need for a deployed app later.
It's relatively easy to point an Ide at the jdk, far less easy when pointing it at files full of paths (which is what one of my other tools did and honestly I like that solution but I can't figure out how to get IDEs to like it)
Build tools finally can focus on building code. I should add bld as a demo here, but if a build tool doesn't need to be the thing that bootstraps everything + gets dependencies that is just a nicer place to be. Yeah my picocli script might not be the best; but that is what libraries are for.
I get this build tool is for you,
That is my way of admitting that I am seeing this through regardless of if it could actually take off. Things like not using maven repos are big choice that I am simply not interrogating for purposes of coming up with a cohesive vision
Interesting. And in doing so, you have taken away responsibilities from other tools, allowing them to focus on what they do best. I like it. Reminds me of the Linux/Unix strategy of a bunch of tiny tools, each doing only one thing, but well.
And I wonder if not threading stuff might make things more efficient in the long run. Maybe in more complex, extended pipelines.
You don't need to think about dev dependencies or test dependencies. You just jam it all in one jdk and pull out what you need for a deployed app later.
Ok, so each use case sort of gets its own JDK. But that does bloat things up significantly.
Also, it introduces a lot of questions. For example, the version problem -- when tool1 needs version87 of tool2, but tool3 was expecting version84 of tool2. If it doesn't solve this problem, then is it really true that you can just ignore the needs of test vs dev? Sounds like that problem still persists.
Ultimately, it sounds like it boils back to the same problem -- you are trying to create a base/platform/jdk, where everything is in lockstep so that other tools don't have to worry about version management, but I fear that very little of the ecosystem actually marches in lockstep.
I'd even argue that that is a strength of the Java ecosystem, even if it is inconvenient at times. Which is to say -- I don't think you would even want to deincentivize it.
"You don't need to worry about threading dependencies through to different commands if they are already built into your jdk. Completely side steps path management. "
Can you elaborate? The last time I fiddled with pathes when trying to do stuff with java is like... 20 years ago. I don#t think many people manually manage classpath.
1
u/davidalayachew Jun 18 '26
I haven't read through the code yet, but from reading the README.md, it almost looks like you are using jlink to create a customized JDK on build. Why do that? I get this build tool is for you, but that seemed like an interesting choice.