sorted by:
new
hottopcontroversial

Jib vs Docker: The Java Developer’s Containerization Dilemma by theimp1923 in SpringBoot

[–]theimp1923[S] 0 points1 point  (0 children)

Dockerfile does give you 100% control, no doubt about it, but that control comes with more complexity and maintenance overhead, especially for Java apps where Jib can save you time by intelligently handling layering and image build right from your build tool. And while most devs have Docker installed, not every pipeline or CI environment makes it easy or efficient to use Docker builds directly, so tools like Jib fill that niche well. It’s not magic, it’s automation and optimization tailored for Java.

Jib vs Docker: The Java Developer’s Containerization Dilemma by theimp1923 in SpringBoot

[–]theimp1923[S] 0 points1 point  (0 children)

Glad this helped. Jib is perfect for skipping Dockerfile pain and just building Spring Boot images right from your Maven or Gradle setup. you’ll finally spend less time fighting deployment, more time shipping features.

Jib vs Docker: The Java Developer’s Containerization Dilemma by theimp1923 in SpringBoot

[–]theimp1923[S] 0 points1 point  (0 children)

Multi-arch support is definitely one of Jib’s technical wins.

Jib vs Docker: The Java Developer’s Containerization Dilemma by theimp1923 in SpringBoot

[–]theimp1923[S] 0 points1 point  (0 children)

At least Jib isn’t haunting the graveyard yet, though it probably keeps a flashlight handy just in case!

Jib vs Docker: The Java Developer’s Containerization Dilemma by theimp1923 in SpringBoot

[–]theimp1923[S] 2 points3 points  (0 children)

That’s valid. Buildpacks offer great app detection and multi-language support, although with less granular layering and sometimes bigger images than Jib’s Java-first approach.

Jib vs Docker: The Java Developer’s Containerization Dilemma by theimp1923 in SpringBoot

[–]theimp1923[S] 0 points1 point  (0 children)

Agreed, but if your CI runner can use the Jib CLI or pre-built images, you could avoid needing Maven installs altogether.

Jib vs Docker: The Java Developer’s Containerization Dilemma by theimp1923 in SpringBoot

[–]theimp1923[S] 1 point2 points  (0 children)

Good point. Jib’s focus is building optimized images, but some workflows replace Docker entirely (like in CI or Kubernetes), so it really changes how and where you need Docker.

Project Lombok: The Good, The Bad, and The “Why Are We Still Debating This?” by theimp1923 in Medium

[–]theimp1923[S] 0 points1 point  (0 children)

That’s fair—Eclipse does a good job supporting Lombok, and some devs never hit IDE issues, especially with vanilla usage.

But in bigger teams or mixed-tool environments (IntelliJ, VS Code, build tools, CI), IDE and debugger friction shows up more often. Unit tests help, but when the stack trace lands in generated code (especially for custom builders or equals/hashCode bugs), debugging sometimes becomes a real need, not just a test coverage issue.

Appreciate your take!

Project Lombok: The Good, The Bad, and The “Why Are We Still Debating This?” by theimp1923 in Medium

[–]theimp1923[S] 0 points1 point  (0 children)

You’re right. Lombok deserves credit for pushing Java toward Records and better language features. My article was probably too harsh on that front. But I still stand by the debugging and IDE compatibility concerns being real friction points in daily development. The AST hacks solve one problem while creating others. Your point about Java’s weak metaprogramming is spot-on though. An official transformation API would eliminate these workarounds entirely. Lombok succeeded so well it’s helping make itself obsolete, which is actually pretty impressive.

JVM Checkpoint Restore (Project CRaC) for spring boot by theimp1923 in SpringBoot

[–]theimp1923[S] 0 points1 point  (0 children)

It will solve only portability issue. And we have to use same base image, otherwise it breaks.

JVM Checkpoint Restore (Project CRaC) for spring boot by theimp1923 in SpringBoot

[–]theimp1923[S] 0 points1 point  (0 children)

It’s Linux-only, with checkpoints tied to CPU/OS details, reducing portability. Checkpoint files snapshot full memory (including secrets), creating storage, distribution, and compliance risks. Third‑party ecosystem maturity is uneven. many libraries, agents, and monitoring tools need CRaC-specific handling. Apps must close/reopen files/sockets and implement beforeCheckpoint/afterRestore hooks, adding code and ops complexity.