Setting up a microservices project locally shouldn't feel like a second job. Kubernetes in production is powerful — but onboarding a new developer? That's where things get painful. Docker Compose helps, but it's not always enough. And Makefiles? Another syntax to learn, another tool to maintain, another dependency to worry about. So I asked myself: what if I just used Java? Thanks to Adam Bien's Java Shorts — his talks, his podcast, and his relentless focus on simplicity — I was reminded that modern Java (25!) can run .java files directly, without compilation. So I built my Makefile in Java. One file. Zero extra dependencies. Pure Java. java Makefile.java build java Makefile.java helm-install java Makefile.java k8s-status The result: a full local dev automation tool covering Maven builds, Docker image builds, Helm chart lifecycle, Kubernetes status, API testing, and even opening Kafka UI in the browser. Why it matters: ✅ No new language to learn — it's just Java ✅ Every Java developer on the team can read and contribute to it ✅ One less dependency = one less supply chain attack vector ✅ Same automation logic works locally and in CI/CD Thank you Adam Bien for showing that the best tool is often the one you already know. 🔗 https://lnkd.in/dVR5n9T9 #Java #Java25 #Microservices #Kubernetes #DeveloperExperience #DevOps #AdamBien #CleanCode
Adam Bien
6d
You might like: https://github.com/adambien/z - a collection of Java 25 scripts / ideas
Adam Bien
1w
This looks great! The advantages of Java 25 are its easy installation and the fact that it has no external dependencies, which eliminates any supply chain security risks posed by external libraries.
This resonates a lot. The friction of getting a microservices stack running locally is often underestimated, and it quickly becomes a productivity drain for teams. I really like the idea of leveraging plain Java as the orchestration layer. It removes an entire class of cognitive overhead—no context switching into Make, Bash, or YAML-heavy glue code—and keeps everything in a language the team already understands well. That’s a pragmatic take on “developer experience first.” Also, the point about reducing dependencies (and by extension, supply chain surface area) is underrated. Fewer moving parts usually means fewer surprises. Curious how you’re handling things like parallel execution and environment configuration within this setup—did you lean on ProcessBuilder or something higher-level? Great example of using existing tools creatively instead of adding more layers. 👏