A neat Java idea from JDK 24 preview: JEP 487, Scoped Values.
Scoped values aim to make shared immutable context easier to reason about than ThreadLocal, especially in modern concurrent code.
Tiny example ๐
Posts by BellSoft
This Thursday at #JCON in Cologne, @asm0dey.site is speaking on From Git Panic to Git Zen: With a Little Help from AI.
Reflog, bisect, interactive rebase, and how AI + a custom MCP server backend can make advanced Git a lot less painful.
๐
Apr 23, 14:30โ15:15
๐ Cinema 7
Amsterdam, yesterday evening ๐ณ๐ฑ
Dmitry Chuyko spoke at the Amsterdam JUG Meetup at OpenValue on JDK Doping: Performance Gains Without Touching Your Code. Thanks to everyone who joined!
That is the real roadmap in one line: not learning everything, but learning the right things in the right sequence. If you want the full walkthrough, @asm0dey.site covers it here: youtu.be/tSDCpN3I2_s
๐บ Roadmap PDF: drive.google.com/file/d/1bbsb...
Level 8 is concurrency. This is where you earn the right to use java.util.concurrent, threads, executors, and synchronization without turning your app into a science experiment.
Level 7 is deployment and infrastructure. Docker, CI/CD, GitHub Actions, Jenkins. Shipping code is a separate skill from writing it, and most roadmaps treat it like an afterthought.
Level 6 is testing and code quality. Unit tests, integration tests, mocking, faking, and then more advanced approaches like mutation testing, property-based testing, or BDD. Production code is not just code that works once, but code you can trust to keep working.
Level 5 is the enterprise web stack. Spring Web, Spring Data, Spring Security, dependency injection, and the broader backend model around them. Spring matters, but it lands much better once the lower levels are already in place.
Level 4 is data persistence, and this is where the ordering really matters. Learn SQL and JDBC before Hibernate or JPA. If you skip the database layer and jump straight into ORM, you end up using abstractions you do not really understand.
Level 3 is development and build tools. Git, GitHub or GitLab, IntelliJ IDEA, debugging, refactoring, Maven, Gradle. This is the part many beginners underestimate, even though it shapes how real work gets done every day.
Level 2 is the standard library. Collections, generics, lambdas, streams, Optional, records, file I/O, StringBuilder, Date and Time, Math. This is where Java starts feeling like a language you can work with, not just memorize.
Level 1 is the core: syntax, control flow, arrays, classes, objects, OOP, exceptions, package structure, classpath, and the basic Java toolchain. If this layer is shaky, everything built on top of it stays shaky too.
The main mistake is not lacking motivation or talent. It is learning out of order. A lot of people jump into Spring too early, skip SQL, or confuse using tools with understanding how systems actually work.
๐งต THREAD: Java Developer Roadmap 2026. If you want a clearer map of what to learn next, this is the sequence that gets people from basics to production: core Java, tools, SQL, Spring, testing, deployment, and concurrency.
Spring I/O is over, and the best part as always was the people. Thanks for the booth chats, the talk questions, the #Java debates, and the good energy all the way through. Until next time ๐
Delivered in JDK 22, JEP 454 gave Java a standard Foreign Function & Memory API. Calling native code no longer has to start with JNI boilerplate. Tiny example ๐
Tomorrow at @springio.net, 15:30 in Track 5: @asm0dey.site and @edelveis.dev present The Persistence Heavyweight Championship: JPA vs. jOOQ ๐ฅ
N+1, Criteria API, code generation, runtime performance, and audience voting after each round.
Come help decide who takes the belt!
Missed the buildpacks session with @edelveis.dev and Joe Kutner? The recording is up. Good watch if you want a clearer picture of what gaps buildpacks close and where they make more sense than hand-written Dockerfiles. www.youtube.com/live/x0uLOhh...
Barcelona, day 1 of @springio.net, and we are already at the booth. ๐
Come by for #Java chats, BellSoft Hardened Images, and Liberica JDK, the Java runtime recommended by Spring. Also yes, the Steam Deck raffle is back, and so are the limited-edition shirts! See you there ๐
This Wednesday at @springio.net, 9:00 in Track 5: Dmitry Chuyko on SBOMs and what it takes to make them useful in the real world. CI/CD policies, hardened containers, Kubernetes checks, SPDX vs CycloneDX, and supply chain security that does more than sit in a report. Come catch the talk!
A fresh draft JEP with big day-to-day potential: convenience methods for JSON documents. The idea is JSON parsing in the JDK with low ceremony via the incubating module jdk.incubator.json, so simple lookups can be as short as Json.parse(...).get(...).string(). openjdk.org/jeps/8344154
Tiny example ๐
Setting Xmx is not the same thing as understanding JVM memory. This video with @edelveis.dev breaks down what else eats RAM in a #Java process, which flags matter, and how to tune memory without turning your JVM into a superstition project: youtu.be/wkevk6kYmQY
๐ If you want the full walkthrough, @edelveis.dev covers all 13 practices in the video here: youtu.be/TyNGjP3PbLo
๐ More detail and extra examples are in the article: bell-sw.com/blog/docker-...
Last piece: host hardening. Containers share the host kernel, so image security is never just about the image. Least privilege, patched hosts, LSMs, seccomp, and sane node OS choices still matter.
Also: no secrets in images, and no blind trust in scanners. Secrets belong in runtime secret stores. Scanners answer how risky the artifact looks, but your pipeline still needs policies that decide block, allow, or quarantine.
Do not improvise base images. Start from a maintained base with a real update policy and a trusted vendor, prefer LTS where it makes sense, and rebuild regularly when upstream fixes land. A trusted base that never gets rebuilt is still old software.
And do not stop at inventory. Provenance tells you where the image came from and how it was built, while attestations give consumers something they can verify independently. That is where signing and Cosign step into the limelight.
Prove what is inside. Generate an SBOM for every image at build time so you know exactly what shipped and can map new CVEs back to the affected artifact fast. Without that inventory, remediation gets slower and guessier.
The next step is determinism. Pin toolchains, dependencies, and especially base images by digest, not just by tag. If the same inputs do not reliably produce the same artifact, it becomes much harder to detect tampering or unexpected dependency drift.
Immutability is not aesthetics. If people patch containers in prod, install packages on the fly, or tweak configs inside a running container, the thing in production no longer matches what you built, scanned, and signed. Rebuild and redeploy instead.