Post-OOP Imperative Functional Java.
Model the process. Not the domain.

Most Java code still asks the wrong question:
"What is this domain object?"
But production systems fail, scale, and burn because of processes, not nouns.

If your system is a sequence of irreversible steps, model it as a sequence,
not as interacting objects pretending to be immortal.

This follows ideas from Railway-Oriented Programming (ROP):
errors and decisions are values, not control-flow side effects.

Modeling the process means you can read this top to bottom
and understand exactly what happens.
No debugger. No IDE magic. No tribal knowledge.

Control flow is explicit.
You see the execution order.
Nothing hides in constructors, annotations, or overrides.

Failure is a first-class concept.
Once it fails or decides early, nothing else runs.
No exception archaeology.

Processes > Objects.
Real systems are workflows where refactoring is safe.

Steps are reordered, removed, or replaced
without collapsing a class hierarchy.
Testing is trivial, small stepwise context — even for an AI.

Feed input. Assert final result.
No mocking five layers of indirection.

GraalVM / native-friendly.
No reflection rituals.
The compiler smiles.

Objects are great for long-lived entities.
User actions, payments, rules, and failures are short-lived processes.

I model what happens,
not what pretends to exist forever.

Influenced by:
Railway-Oriented Programming,
Functional Core / Imperative Shell,
Workflow / Saga patterns,
Command pipelines,
Unix philosophy,
and value-oriented libraries like Vanilla-DI.

Don't be stuck in axioms.

#PostOOP
#ImperativeFunctional
#ProcessOverObjects
#ModelTheProcess
#WorkflowFirst
#RailwayOrientedProgramming
#FunctionalCore
#ImperativeShell
#CommandPipeline
#ExplicitControlFlow
#ValueOrientedDesign
#ProcessModeling
#FailFast
#NoExceptionArchaeology
#ComposableSystems
#NativeFriendly
#GraalVM
#NoReflection
#DeterministicCode
#RefactorSafe
#SagaPattern
#UnixPhilosophy
#VanillaDI
#ModernJava
#ArchitectureMatters

#Java now lets you match inside records, compare primitives, & run full apps without touching #Maven. @ronveen takes you inside a version where syntax, tooling & mindset finally align.

Start here: https://javapro.io/2025/06/17/modern-java/

#PatternMatching #ModernJava #VirtualThreads #ProjectLoom

Don’t start from scratch.
Quarkus supports your Spring annotations — @Controller, @Service, @Repository.
Migrate your app module-by-module and go cloud-native without breaking everything.
#SpringBoot #Quarkus #DeveloperExperience #JavaMigration #ModernJava

https://quarkus.io/spring/

Spring muscle memory? Keep it.
Quarkus supports your existing annotations like @RestController, @Autowired, @Repository — just faster. Migrate incrementally and ship apps with a native edge.
#SpringBoot #Java #Quarkus #DeveloperExperience #ModernJava #CloudNative

https://quarkus.io/spring/

Quarkus speaks fluent Spring—reuse your @RestController, @Autowired, and JpaRepository code with Spring compatibility extensions. 👩💻
Same familiar APIs. Blazing-fast, cloud-native runtime.

#Java #SpringBoot #Quarkus #CloudNative #ModernJava #SpringCompatibility

https://quarkus.io/spring/

#Java now streams with memory, discards threads instead of pooling & runs without public static void main. #VirtualThreads, Gatherers & no-boilerplate coding—@ronveen breaks down the quiet revolution

Read: https://javapro.io/2025/06/17/modern-java/

#ModernJava #ProjectLoom #StructuredConcurrency

Why @Annotations Will Eventually Burn You.

Preach annotation voodoo or embrace explicit method calls? Too many still cling to @PreAuthorize, entrusting their fate to framework black magic. But such blind faith is brittle. One innocent Spring Boot update, and suddenly your security vanishes unless you summon an obscure @Enable... incantation.

Prefer the custom preauthorize() method: it’s concrete, predictable, and the compiler screams when something breaks as it should. Just like how constructor injection finally defeated the field-injection cult, it’s time to retire annotation worship elsewhere too.

Consider @JsonProperty("fieldName"): sure, the object mapper might infer names correctly without it, until one day it doesn’t, because the naming strategy changes behind your back. It’s happened. It will happen again. That’s the price of depending on invisible magic. Unreadable, unpredictable, unmaintainable. Same applies to reflection.

Frameworks and their “best practices” are relics of the monolith age. Java has evolved: threads, HTTP services, logging,… all can now be built functionally, fluently, and natively. It’s not Java vs Kotlin or some trendy syntax candy. Languages, especially those that compile, already give you more than enough. The bottleneck isn’t the tool, it’s the one holding it.

#Java #SpringBoot #CleanCode #SoftwareEngineering #CodeQuality #Programming #ModernJava #DeveloperExperience #DevMindset #NoMoreMagic #ReadableCode #ExplicitOverImplicit #SayNoToAnnotations #SeparationOfConcerns #FunctionalProgramming

#java luminaries meeting before the start of @jcon
Currently the group is sharing many opinions on how to get "young" developers interested in #modernJava.

1995: #Java is slow.
2025: Java is almost too fast to comprehend.
Join @javacoding on a #Performance journey through 30 years of #JVM evolution.

How did Java get this fast? Find out here:
https://javapro.io/2025/04/07/hitchhikers-guide-to-java-performance/

#ModernJava #GraalVM #ProjectLoom #GarbageCollection #ZGC

Hitchhiker's Guide to Java Performance - JAVAPRO International

The Past, The Present and The Future Over the last 30 years, Java has evolved from an exotic…

JAVAPRO International

Java Is Becoming a Monster (And I Love It)
I used to think Java was done. Stale. Verbose. A relic.
But now? It mutated. It spawns 5000 virtual threads like it’s nothing.

I just built a REST service:
✅ Runs on virtual threads
✅ Functional pipelines
✅ Only a few MB RAM
✅ No thread-pools
✅ No leaks
✅ Pure JVM

This isn't Java 8 anymore.

✨ No Groovy. No Kotlin. No detours.
Java is now useful and gets Beautiful.

And then there’s GraalVM:
If you skip reflection and runtime init, you get:
⚡ Native executables
⚡ Instant startup
⚡ Tiny memory
⚡ No runtime surprises

Game. Changed.

But OSS frameworks?
Still look frozen in 2015.
Heavy, reflective, runtime-hacked monsters.

So I built my own tools:

🔥 TypeMap
→ Zero-reflection json/xlm reader & type converter
→ GraalVM native
→ Fast. Simple. Functional.
https://github.com/YunaBraska/type-map

⚔️ Nano
→ Anti-framework
→ Static main, no DI magic
→ Pure, clean design
https://github.com/NanoNative/nano

🧪 Nano example app
➡️ One single static main file
https://github.com/YunaBraska/nano-graalvm-example

🛠 API-Doc-Crafter
➡️ Native CLI doc tool
https://github.com/YunaBraska/api-doc-crafter

🧭 My Java Functional Guidelines
https://devabyss.hashnode.dev/java-functional-guidelines

Java isn't just catching up.
It’s setting the pace now.

The only question is:
Can frameworks and libraries keep up?

#Java #GraalVM #VirtualThreads #FunctionalProgramming #JVM #ModernJava #coding #Programming

GitHub - YunaBraska/type-map: TypeMap and TypeConverter for a dynamic, extendable, high-performance type conversion library that's native-ready for GraalVM. This robust Java utility provides type-safe retrieval and conversion, leveraging ConcurrentHashMap for thread-safe operations without reflection.

TypeMap and TypeConverter for a dynamic, extendable, high-performance type conversion library that's native-ready for GraalVM. This robust Java utility provides type-safe retrieval and conversi...

GitHub