Jonathan Lalou's Blog

Posts Tagged ‘DevoxxBE2025’

Lecturer

Balkrishna Rawool leads IT chapters at ING Bank, focusing on scalable software solutions and Java concurrency. He actively shares insights on Project Loom through conferences and writings, drawing from practical implementations in financial systems.

Abstract

This review dissects Project Loom’s enhancements to Java’s concurrency: virtual threads for efficient multitasking, structured concurrency for task orchestration, and scoped values for secure data sharing. Placed in web development contexts, it explains their interfaces and combined usage via a Spring Boot loan processing app. The evaluation covers integration techniques, traditional threading issues, and effects on legibility, expandability, and upkeep in parallel code.

Project Loom Foundations and Virtual Threads

Project Loom overhauls Java concurrency with lightweight alternatives to OS-bound threads, which limit scale due to overheads. Virtual threads, managed by the JVM, enable vast concurrency on few carriers, ideal for IO-heavy web services.

In the loan app—computing offers via credit, account, and loan calls—virtual threads parallelize without resource strain. Configuring Tomcat to use them boosts TPS from hundreds to thousands, as non-blocking calls unmount threads.

The interface mirrors traditional: Thread.ofVirtual().start(task). Internals use continuations for suspension, allowing carrier reuse. Consequences: lower memory, natural exception flow.

Care needed for pinning: synchronized blocks block carriers; ReentrantLocks avoid this, sustaining performance.

Structured Concurrency for Unified Task Control

Structured concurrency organizes subtasks as cohesive units, addressing executors’ scattering. StructuredTaskScope scopes forks, ensuring completion before progression.

In the app, scoping credit/account/loan forks with ShutdownOnFailure cancels on errors, avoiding leaks. Example:

try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
    var credit = scope.fork(() -> getCredit(request));
    var account = scope.fork(() -> getAccount(request));
    var loan = scope.fork(() -> calculateLoan(request));
    scope.join();
    // Aggregate
} catch (Exception e) {
    // Manage
}

This ensures orderly shutdowns, contrasting unstructured daemons. Effects: simpler debugging, no dangling tasks.

Scoped Values for Immutable Inheritance

Scoped values supplant ThreadLocals for virtual threads, binding data immutably in scopes. ThreadLocals mutate, risking inconsistencies; scoped values inherit safely.

For request IDs in logs: ScopedValue.where(ID, uuid).run(() -> tasks); IDs propagate to forks via scopes.

Example:

ScopedValue.where(REQ_ID, UUID.randomUUID()).run(() -> {
    // Forks access ID
});

This solves ThreadLocal inefficiencies in Loom. Effects: secure sharing in hierarchies.

Combined Usage and Prospects

Synergies yield maintainable concurrency: virtual threads scale, scopes structure, values share. The app processes concurrently yet organized, IDs tracing.

Effects: higher IO throughput, easier upkeep. Prospects: framework integrations reshaping concurrency.

In overview, Loom’s features enable efficient, readable parallel systems.

Links:

• Lecture video: https://www.youtube.com/watch?v=iO79VR0zAhQ
• Balkrishna Rawool on LinkedIn: https://nl.linkedin.com/in/balkrishnarawool
• Balkrishna Rawool on Twitter/X: https://twitter.com/BalaRawool
• ING Bank website: https://www.ing.com/

Lecturer

Thomas Pierrain is Vice President of Engineering at Agicap, a financial management platform, where he applies domain-driven design to build scalable systems. Julien Topcu is Vice President of Technology at SHODO Group, a consultancy focused on socio-technical coaching and architecture, with expertise in helping teams implement domain-driven practices.

Abstract

This analysis investigates the Hive pattern, an architectural approach for creating modular monoliths that support easy evolution to microservices. It identifies key ideas like vertical slicing and port-adapter boundaries, set against the backdrop of microservices pitfalls. Highlighting a live-refactored time-travel system, it details methods for domain alignment, encapsulation, and simulated distributed communication. Consequences for system flexibility, debt management, and scalability are evaluated, providing insights into resilient designs for existing and new developments.

Emergence from Microservices Challenges

Over a decade, the shift to microservices has often resulted in distributed messes, worse than the monoliths they replaced due to added complexity in coordination and deployment. The modular monolith concept arises as a remedy, but risks tight coupling if not properly segmented. The Hive addresses this by separating design from deployment, following “construct once, deploy flexibly.”

In the live example, a time-machine’s control system—handling energy, navigation, and diagnostics—crashes due to fragility, landing in the 1980s. Diagnostics reveal a muddled structure with high resource use, mirroring legacy systems burdened by modeling debt—the buildup of imprecise domain models hindering change.

The pattern’s innovation lies in fractal composability: modules as hexagons can nest or extract as services. This enables scaling in (sub-modules) or out (microservices), adapting to needs like independent deployment for high-load components.

Essential Tenets of the Hive

Vertical slicing packs modules with all necessities—logic, storage, interfaces—for self-sufficiency, avoiding shared layers’ dependencies. In the demo, the energy module includes its database, isolating it from navigation.

Port-adapter encapsulation defines interaction points: inbound for incoming, outbound for outgoing. Adapters translate, eliminating direct links. The navigation’s energy request port uses an adapter to call the energy’s provision port, preventing tangles.

Inter-module talks mimic microservices sans networks, using in-process events. This readies for distribution: swapping adapters for remote calls extracts modules seamlessly. The example routes via a bus, allowing monolith operation with distributed readiness.

These tenets create a supple framework, resilient to evolution. The fractal aspect allows infinite composition, as shown by nesting diagnostics within navigation.

Refactoring Methodology and Practical Steps

The session starts with a monolithic system showing instability: overused resources cause anomalies. AI schemas expose entanglements, guiding domain identification—energy, time circuits, AI.

Modules reorganize: each hexagon sliced vertically with dedicated storage. Code moves via IDE tools, databases split to prevent sharing. Energy gains PostgreSQL, queried through adapters.

Communication restructures: ports define contracts, adapters implement. Navigation’s outbound energy port adapts to energy’s inbound, using events for asynchrony.

Extraction demonstrates: energy becomes a microservice by changing adapters to network-based, deploying separately without core changes. Tests modularize similarly, using mocks for isolation.

This step-by-step approach handles brownfields incrementally, using tools for safe restructuring.

Resilience, Scalability, and Debt Mitigation

Hive’s boundaries enhance resilience: changes localize, as energy tweaks affect only its hexagon. This curbs debt, allowing independent domain refinement.

Scalability is fractal: inward nesting subdivides, outward extraction distributes. Networkless talks ease transitions, minimizing rewrites.

Versus monoliths’ coupling or microservices’ prematurity, Hive balances, domain-focused for “right-sized” architectures. Challenges: upfront refactoring, boundary discipline.

Development Ramifications and Adoption

Hive promotes adaptive designs for changing businesses. Starting modular prevents debt in new projects; modernizes legacies via paths shown.

Wider effects: better sustainment, lower costs through contained modules. As hype fades, Hive provides hybrids, emphasizing appropriate sizing.

Future: broader use in frameworks, tools for pattern enforcement.

In overview, Hive exemplifies composable resilience, merging monolith unity with microservices adaptability.

Links:

• Lecture video: https://www.youtube.com/watch?v=VKcRNtj0tzc
• Thomas Pierrain on LinkedIn: https://fr.linkedin.com/in/thomas-p-0664769
• Thomas Pierrain on Twitter/X: https://twitter.com/tpierrain
• Julien Topcu on LinkedIn: https://fr.linkedin.com/in/julien-top%25C3%25A7u
• Agicap website: https://agicap.com/
• SHODO Group website: https://shodo.io/

Lecturer

Per Minborg is a Java Core Library Developer at Oracle, specializing in language features and performance improvements. He has contributed to projects enhancing Java’s concurrency and immutability models, drawing from his background in database acceleration tools like Speedment.

Abstract

This investigation explores Java’s ‘final’ keyword as a mechanism for immutability, examining its semantic guarantees from compilation to runtime execution. It contextualizes the balance between mutable flexibility and immutable predictability, delving into JVM trust dynamics and recent proposals like strict finals. Through code demonstrations and JVM internals, the narrative assesses approaches for stronger immutability, including lazy constants, and their effects on threading, optimization, and application speed. Forward implications for Java’s roadmap are considered, emphasizing enhanced reliability and efficiency.

Balancing Mutability and Immutability in Java

Java’s design philosophy accommodates both mutability for dynamic state changes and immutability for stability, yet tensions arise in performance and safety. Immutability, praised in resources like Effective Java, ensures objects maintain a single state, enabling safe concurrent access without locks. Immutable instances can be cached or reused, functioning reliably as keys in collections—unlike mutables that may cause hash inconsistencies after alterations.

Mutability, however, provides adaptability for evolving data, crucial in interactive systems. The ‘final’ keyword aims to enforce constancy, but runtime behaviors complicate this. Declaring ‘final int value = 42;’ implies permanence, yet advanced techniques like reflection with Unsafe can modify it, breaching expectations.

This duality impacts optimizations: trusted finals allow constant propagation, minimizing memory accesses. Yet, Java permits post-constructor updates for deserialization, eroding trust. Demonstrations show reflection altering finals, highlighting vulnerabilities where JVMs must hedge against changes, forgoing inlining.

Historically, Java prioritized flexibility, allowing such mutations for practicality, but contemporary demands favor integrity. Initiatives like “final truly final” seek to ban post-construction changes, bolstering trust for aggressive enhancements.

JVM Trust Mechanisms and Final Field Handling

JVM trust refers to assuming ‘final’ fields remain unchanged post-initialization, enabling efficiencies like constant folding. Current semantics, however, permit reflective or deserialization modifications, limiting optimizations.

Examples illustrate:

class Coordinate {
    final int coord;
    Coordinate(int coord) { this.coord = coord; }
}

Post-constructor, ‘coord’ is trusted, supporting optimizations. Reflection via Field.setAccessible(true) overrides this, as Unsafe manipulations demonstrate. Performance tests reveal trusted finals outperform volatiles in accesses, but untrusted ones underperform.

Java’s model historically allowed mutations for deserialization, but stricter enforcement proposals aim to restrict this. Implications include safer multi-threading, as finals ensure visibility without volatiles.

Advancements in Strict Finals and Leak Prevention

Strict finals strengthen guarantees by prohibiting constructor leaks—publishing ‘this’ before all finals are set. This prevents partial states in concurrent environments, where threads might observe defaults like zero before assignments.

Problematic code:

class LeakyClass {
    final int val = 42;
    LeakyClass() { Registry.register(this); } // Leak
}

Leaks risk threads seeing val=0. Strict finals reject this at compile time, enforcing safe initialization.

Methodologically, this requires refactoring to avoid early publications, but yields threading reliability and optimization opportunities. Benchmarks quantify benefits: trusted paths execute quicker, with fewer barriers.

Lazy Constants for Deferred Initialization

Previewed in Java 25, lazy constants merge mutable deferral with final optimizations. Declared ‘lazy final int val;’, they compute once on access via suppliers:

lazy final int heavy = () -> heavyComputation();

JVM views them as constants after initialization, supporting folding. Use cases include infrequent or expensive values, avoiding startup costs.

Unlike volatiles, lazy constants ensure at-most-once execution, with threads blocking on contention. This fits singletons or caches, surpassing synchronized options in efficiency.

Roadmap and Performance Consequences

Strict finals and lazy constants fortify Java’s immutability, complementing concurrent trends. Consequences include accelerated, secure code, with JVMs exploiting trust for vector operations.

Developers balance: finals for absolutes, lazies for postponements. Roadmaps indicate stabilization in Java 26, expanding usage.

In overview, these evolutions make ‘final’ definitively final, boosting Java’s sturdiness and proficiency.

Links:

• Lecture video: https://www.youtube.com/watch?v=J754RsoUd00
• Per Minborg on Twitter/X: https://twitter.com/PMinborg
• Oracle website: https://www.oracle.com/

Lecturer

Scott Sosna is a seasoned technologist with diverse roles in software architecture and backend development. Currently an individual contributor at a SaaS firm, he mentors emerging engineers and authors on code quality and organizational dynamics.

Abstract

This discourse analogizes codebases to crime scenes, identifying organizational triggers for quality degradation such as misaligned incentives, political maneuvers, and procedural lapses. Contextualized within career progression, it analyzes methodologies for self-protection, ally cultivation, and continuous improvement. Through anecdotal examinations of common pitfalls, the narrative evaluates implications for maintainability, team morale, and professional resilience, advocating proactive strategies in dysfunctional environments.

Organizational Triggers and Code Degradation

Codebases often devolve due to systemic issues rather than individual failings, akin to unsolved mysteries where clues point to broader culprits. Sales commitments override engineering feasibility, imposing unrealistic timelines that foster shortcuts. In one anecdote, promised features without consultation led to hastily patched legacy systems, birthing unmaintainable hybrids.

Politics exacerbate this: non-technical leaders dictate architectures, as when a director mandated a shift to NoSQL sans rationale, yielding mismatched solutions. Procedural gaps, like absent reviews, allow unchecked merges, propagating errors. Contextualized, these stem from misaligned incentives—sales bonuses prioritize deals over sustainability, while engineers bear long-term burdens.

Implications include accrued technical debt, manifesting as fragile systems prone to outages. Analysis reveals patterns: unchecked merges correlate with higher defect rates, underscoring review necessities.

Interpersonal Dynamics and Blame Cultures

Blame cultures stifle innovation, where finger-pointing overshadows resolution. Anecdotes illustrate managers evading accountability, redirecting faults to teams. This erodes trust, prompting defensive coding over optimal solutions.

Methodologically, fostering psychological safety counters this: encouraging open post-mortems focuses on processes, not persons. In dysfunctional settings, documentation becomes armor—recording decisions shields against retroactive critiques.

Implications affect morale: persistent blame accelerates burnout, increasing turnover. Analysis suggests ally networks mitigate this, amplifying voices in adversarial environments.

Strategies for Professional Resilience

Resilience demands proactive measures: continual self-improvement via external learning equips engineers for advocacy. Cultivating allies—trusted colleagues who endorse approaches—extends influence, socializing best practices.

Experience tempers reactions: seasoned professionals discern battles, conserving energy for impactful changes. Exit strategies, whether role shifts or departures, preserve well-being when reforms falter.

Implications foster longevity: adaptive engineers thrive, contributing sustainably. Analysis emphasizes balance—technical excellence paired with soft skills navigates organizational complexities.

Pathways to Improvement and Exit Considerations

Improvement pathways include feedback loops: rating systems in tools like conference apps aggregate insights, informing enhancements. External perspectives, like articles on engineering misconceptions, offer fresh viewpoints.

When irreconcilable, exits—internal or external—rejuvenate careers. Market challenges notwithstanding, skill diversification bolsters options.

In conclusion, viewing codebases as crime scenes unveils systemic flaws, empowering engineers with strategies for navigation and reform, ensuring professional fulfillment amid adversities.

Links:

• Lecture video: https://www.youtube.com/watch?v=-iKd__Lzt7w
• Scott Sosna on LinkedIn: https://www.linkedin.com/in/scott-sosna-839b4a1/

Lecturer

Brian Clozel contributes as a core developer on Spring initiatives at Broadcom, emphasizing reactive web technologies and framework integrations. Stephane Nicoll leads efforts on Spring Boot at Broadcom, focusing on configuration and tooling enhancements for developer efficiency.

Abstract

This review investigates Spring Boot 4.0’s enhancements, centering on migrations from prior releases, null safety integrations, dependency granularities, and asynchronous client usages. Framed by Java’s progression, it assesses upgrade tactics, utilizing JSpecify for null checks and Jackson 3 for serialization. Via an upgrade of a gaming matchmaking component, the narrative appraises effects on dependability, throughput, and creator workflow, with consequences for non-reactive concurrency and onward interoperability.

Progression of Spring Boot and Migration Drivers

Spring Boot has streamlined Java creation through automated setups and unified ecosystems, yet advancing standards require periodic refreshes. Release 4.0 retains Java 17 baseline, permitting utilization of fresh syntax sans runtime shifts. This constancy supports organizations with fixed setups, while adopting trials like Java 25’s terse entry points shows prospective alignment.

Migration commences with harmonizing imports: refreshing the overarching POM or incorporating the import plugin secures uniform releases. In the matchmaking component—retrieving gamer details and metrics—the shift uncovers obsoletions, like pivoting from RestTemplate to RestClient. This advancement tackles constraints in blocking clients, fostering adaptable substitutes.

Framed historically, Spring Boot 4 tackles demands for robust, streamlined scripts. Null annotations, embedded through JSpecify, avert operational null errors via build-time inspections. Activating these in assemblers like Gradle identifies risks, as observed when marking elements like gamer identifiers to require non-empty states. This anticipatory safeguard lessens deployment faults, harmonizing with trends toward dependable, foreseeable solutions.

Import refinements additionally frame the shift: precise modules permit discerning additions, refining sizes. For example, isolating network from essentials evades superfluous inclusions, boosting compartmentalization in varied rollouts.

Embedding Progressive Traits and Safeguards

Spring Boot 4 embeds null markers throughout its framework, employing JSpecify to heighten type reliability. In the matchmaking, applying @NonNull to arguments and attributes guarantees build-time confirmation, identifying lapses like unset variables. This system, when triggered in Gradle through assembler flags, merges fluidly with editors for instant alerts.

Jackson 3 embedding typifies updating: advancing from release 2 entails setup tweaks, like activating rigorous null inspections for unmarshalling. In the illustration, unmarshalling gamer metrics gains from refreshed presets, like refined variant management, curtailing templates. Bespoke extensions, like for temporal types, become inherent, rationalizing arrangements while preserving congruence.

The pivot to RestClient for network exchanges handles non-synchronous demands sans responsive models. In the component, substituting blocking invocations with concurrent runs through StructuredTaskScope exemplifies this: spawning duties for details and metrics, then merging outcomes, halves delays from 400ms to 200ms. Triggering trial traits in assemblies permits exploration, offering response cycles for nascent Java proficiencies.

These traits jointly bolster reliability and proficiency, alleviating frequent snares like null accesses and linear constrictions, while upholding Spring’s creator-centric philosophy.

Empirical Shift and Throughput Boosts

Shifting the matchmaking involves orderly phases: refreshing Boot initiators, addressing obsoletions, and polishing setups. Preliminary executions after shift reveal matters like mismatched Jackson releases, rectified by direct inclusions. The component’s API termini, managing gamer lining, gain from polished monitoring: Micrometer’s refreshed gauges offer profounder views into invocation delays.

Non-synchronous boosts through RestClient display methodical grace: building clients with root URIs and timeouts, then running concurrent fetches for details and metrics. Fault management merges organically, with reattempts or reserves adjustable sans responsive types. Throughput records affirm parallelism, showing concrete advances in capacity for demanding contexts like gaming infrastructures.

Import oversight progresses with detailed artifacts: selecting spring-boot-starter-web minus integrated hosts fits encapsulated rollouts. This choosiness lessens artifact dimensions, hastening assemblies and rollouts in automation chains.

The illustration stresses successive authentication: executing coherence checks after alterations assures conduct uniformity, while trial traits like task scopes are switched for trials. This orderly tactic lessens hazards, synchronizing shifts with functional truths.

Extensive Consequences for Java Framework

Spring Boot 4’s progressions solidify its place in contemporary Java, linking conventional and responsive models while adopting syntax advancements. Null inspections elevate script caliber, diminishing flaws in deployment settings. Jackson 3’s embedding streamlines information handling, backing progressing norms like JSON boosts.

For creators, these alterations boost output: self-setups adjust to fresh presets, while utilities like DevTools endure for swift cycles. Consequences stretch to expandability: concurrent network invocations sans reactors fit conventional groups shifting to parallelism.

Prospective paths encompass profounder Java 26 embedding, possibly firming trials like task scopes. Journal assets elaborate these, directing communal embrace.

In overview, Spring Boot 4 polishes the framework’s bases, nurturing safer, efficacious solutions through considerate progressions.

Links:

• Lecture video: https://www.youtube.com/watch?v=4NQCjSsd-Mg
• Brian Clozel on LinkedIn: https://www.linkedin.com/in/bclozel/
• Brian Clozel on Twitter/X: https://twitter.com/bclozel
• Stephane Nicoll on LinkedIn: https://www.linkedin.com/in/stephane-nicoll-425a822/
• Stephane Nicoll on Twitter/X: https://twitter.com/snicoll
• Broadcom website: https://www.broadcom.com/