Posts Tagged ‘DevoxxBE2025’
[DevoxxBE2025] Robotics and GraalVM Native Libraries
Lecturer
Florian Enner is a co-founder and chief software engineer at HEBI Robotics, a company focused on modular robotic systems for research and industrial applications. Holding a Master’s degree in Robotics from Carnegie Mellon University, he has contributed to advancements in real-time control software and hardware integration, with publications in venues like the IEEE International Conference on Robotics and Automation.
Abstract
This article explores the application of Java in robotics development, with a particular emphasis on real-time control and the emerging role of GraalVM’s native shared libraries as a potential substitute for portions of C++ codebases. It elucidates core concepts in modular robotic hardware and software design, positioned within the framework of HEBI Robotics’ efforts to create adaptable platforms for autonomous and inspection tasks. By examining demonstrations of robotic assemblies and code compilation processes, the narrative underscores approaches to achieving platform independence, optimizing execution speed, and incorporating safety protocols. The exploration assesses environmental factors in embedded computing, ramifications for workflow efficiency and system expandability, and offers perspectives on migrating established code for greater development agility.
Innovations in Modular Robotic Components
HEBI Robotics develops interchangeable elements that serve as sophisticated foundational units for assembling tailored robotic configurations, comparable to enhanced construction sets. These encompass drive mechanisms, visual sensors, locomotion foundations, and power sources, engineered to support swift prototyping across sectors like manufacturing oversight and self-governing navigation. The breakthrough resides in the drive units’ unified architecture, merging propulsion elements, position detectors, and regulation circuits into streamlined modules that permit sequential linking, thereby minimizing cabling demands and mitigating intricacies in articulated assemblies.
Situated within the broader landscape of robotics, this methodology counters the segmentation where pre-built options frequently fall short of bespoke requirements. Through standardized yet modifiable parts, HEBI promotes innovation in academic and commercial settings, allowing practitioners to prioritize advanced algorithms over fundamental assembly. For example, drive units facilitate instantaneous regulation at 1 kHz frequencies, incorporating adjustments for voltage fluctuations in portable energy scenarios and protective expirations to avert erratic operations.
Procedurally, the computational framework spans multiple programming environments, accommodating dialects such as Java, C++, Python, and MATLAB to broaden usability. Illustrations depict mechanisms like multi-legged walkers or wheeled units directed through wired or wireless connections, underscoring the arrangement’s durability in practical deployments. Ramifications involve diminished entry thresholds for exploratory groups, fostering accelerated cycles of refinement and more secure implementations, especially for novices or instructional purposes.
Java’s Application in Instantaneous Robotic Regulation
The deployment of Java in robotics contests traditional assumptions regarding its fitness for temporally stringent duties, which have historically been the domain of more direct languages. At HEBI, Java drives regulatory cycles on integrated Linux platforms, capitalizing on its comprehensive toolkit for output while attaining consistent timing. Central to this is the administration of memory reclamation interruptions via meticulous distribution tactics and localized variables for thread-specific information.
The interface conceals equipment details, enabling Java applications to dispatch directives and obtain responses promptly. An elementary Java routine can coordinate a mechanical limb’s motions:
import com.hebi.robotics.*;
public class LimbRegulation {
public static void main(String[] args) {
ModuleSet components = ModuleSet.fromDetection("limb");
Group assembly = components.formAssembly();
Directive dir = Directive.generate();
dir.assignPlacement(new double[]{0.0, Math.PI/2, 0.0}); // Define joint placements
assembly.transmitDirective(dir);
}
}
This script identifies components, organizes a regulatory cluster, and issues placement directives. Protective measures incorporate through directive durations: absence of renewals within designated intervals (e.g., 100 ms) initiates shutdowns, safeguarding against risks.
Placed in perspective, this strategy diverges from C++’s prevalence in constrained devices, providing Java’s strengths in clarity and swift iteration. Examination indicates Java equaling C++ delays in regulatory sequences, with slight burdens alleviated by enhancements like preemptive assembly. Ramifications extend to group formation: Java’s accessibility draws varied expertise, hastening initiative timelines while upholding dependability.
GraalVM’s Native Assembly for Interchangeable Modules
GraalVM’s indigenous compilation converts Java scripts into independent executables or interchangeable modules, offering a pathway to supplant efficiency-vital C++ segments. At HEBI, this is investigated for interchangeable modules, assembling Java logic into .so files invokable from C++.
The procedure entails configuring GraalVM for introspections and assets, then assembling:
native-image --shared -jar mymodule.jar -H:Name=mymodule
This yields an interchangeable module with JNI exports. A basic illustration assembles a Java category with functions revealed for C++ calls:
public class Conference {
public static int sum(int first, int second) {
return first + second;
}
}
Assembled into libconference.so, it is callable from C++. Illustrations confirm successful runs, with “Greetings Conference” output from Java-derived logic.
Situated within robotics’ demand for minimal-delay modules, this connects dialects, permitting Java for reasoning and C++ for boundaries. Efficiency assessments show near-indigenous velocities, with launch benefits over virtual machines. Ramifications involve streamlined upkeep: Java’s protective attributes diminish flaws in regulations, while indigenous assembly guarantees harmony with current C++ frameworks.
Efficiency Examination and Practical Illustrations
Efficiency benchmarks contrast GraalVM modules to C++ counterparts: in sequences, delays are equivalent, with Java’s reclamation regulated for predictability. Practical illustrations encompass serpentine overseers traversing conduits, regulated through Java for trajectory planning.
Examination discloses GraalVM’s promise in constrained contexts, where rapid assemblies (under 5 minutes for minor modules) permit swift refinements. Protective attributes, like speed restrictions, merge effortlessly.
Ramifications: blended codebases capitalize on advantages, boosting expandability for intricate mechanisms like equilibrium platforms involving users.
Prospective Paths in Robotic Computational Frameworks
GraalVM vows additional mergers, such as multilingual modules for fluid multi-dialect calls. HEBI foresees complete Java regulations, lessening C++ dependence for superior output.
Obstacles: guaranteeing temporal assurances in assembled scripts. Prospective: wider integrations in robotic structures.
In overview, GraalVM empowers Java in robotics, fusing proficiency with creator-oriented instruments for novel arrangements.
Links:
- Lecture video: https://www.youtube.com/watch?v=md2JFgegN7U
- Florian Enner on LinkedIn: https://www.linkedin.com/in/florian-enner-59b81466/
- Florian Enner on GitHub: https://github.com/ennerf
- HEBI Robotics website: https://www.hebirobotics.com/
[DevoxxBE2025] Robotics and GraalVM Native Libraries
Lecturer
Florian Enner is the co-founder and chief software engineer at HEBI Robotics, a company specializing in modular robotic systems. With a background in electrical and computer engineering from Carnegie Mellon University, Florian has extensive experience in developing software for real-time robotic control and has contributed to various open-source projects in the field. His work focuses on creating flexible, high-performance robotic solutions for industrial and research applications.
Abstract
This article delves into the integration of Java in custom robotics development, emphasizing real-time control systems and the potential of GraalVM native shared libraries to supplant segments of C++ codebases. It identifies key innovations in modular hardware components and software architectures, situated within HEBI Robotics’ approach to building autonomous and inspection-capable robots. Through demonstrations of robotic platforms and code compilations, the narrative highlights methodologies for cross-platform compatibility, performance optimization, and safety features. The discussion evaluates contextual challenges in embedded systems, implications for development efficiency and scalability, and provides insights into transitioning legacy code for enhanced productivity.
Modular Building Blocks for Custom Robotics
HEBI Robotics specializes in creating versatile components that function as high-end building blocks for constructing bespoke robotic systems, akin to advanced modular kits. These include actuators, cameras, mobile bases, and batteries, designed to enable rapid assembly of robots for diverse applications such as industrial inspections or autonomous navigation. The innovation lies in the actuators’ integrated design, combining motors, encoders, and controllers into compact units that can be daisy-chained, simplifying wiring and reducing complexity in multi-joint systems.
Contextually, this addresses the fragmentation in robotics where off-the-shelf solutions often fail to meet specific needs. By providing standardized yet customizable modules, HEBI facilitates experimentation in research and industry, allowing users to focus on higher-level logic rather than hardware intricacies. For instance, actuators support real-time control at 1 kHz, with features like voltage compensation for battery-powered operations and safety timeouts to prevent uncontrolled movements.
Methodologically, the software stack is cross-platform, supporting languages like Java, C++, Python, and MATLAB, ensuring broad accessibility. Demonstrations showcase robots like hexapods or wheeled platforms controlled via Ethernet or WiFi, highlighting the system’s robustness in real-world scenarios. Implications include lowered barriers for R&D teams, enabling faster iterations and safer deployments, particularly for novices or in educational settings.
Java’s Role in Real-Time Robotic Control
Java’s utilization in robotics challenges conventional views of its suitability for time-critical tasks, traditionally dominated by lower-level languages. At HEBI, Java powers control loops on embedded Linux systems, leveraging its rich ecosystem for productivity while achieving deterministic performance. Key to this is managing garbage collection pauses through careful allocation strategies and using scoped values for thread-local data.
The API abstracts hardware complexities, allowing Java clients to issue commands and receive feedback in real time. For example, a simple Java script can orchestrate a robotic arm’s movements:
import com.hebi.robotics.*;
public class ArmControl {
public static void main(String[] args) {
ModuleSet modules = ModuleSet.fromDiscovery("arm");
Group group = modules.createGroup();
Command cmd = Command.create();
cmd.setPosition(new double[]{0.0, Math.PI/2, 0.0}); // Set joint positions
group.sendCommand(cmd);
}
}
This code discovers modules, forms a control group, and issues position commands. Safety integrates via command lifetimes: if no new command arrives within a specified period (e.g., 100 ms), the system shuts down, preventing hazards.
Contextually, this approach contrasts with C++’s dominance in embedded systems, offering Java’s advantages in readability and rapid development. Analysis shows Java matching C++ latencies in control loops, with minor overheads mitigated by optimizations like ahead-of-time compilation. Implications extend to team composition: Java’s familiarity attracts diverse talent, accelerating project timelines while maintaining reliability.
GraalVM Native Compilation for Shared Libraries
GraalVM’s native image compilation transforms Java code into standalone executables or shared libraries, presenting an opportunity to replace performance-critical C++ components. At HEBI, this is explored for creating .so files callable from C++, blending Java’s productivity with native efficiency.
The process involves configuring GraalVM for reflections and resources, then compiling:
native-image --shared -jar mylib.jar -H:Name=mylib
This generates a shared library with JNI exports. A simple example compiles a Java class with methods exposed for C++ invocation:
public class Devoxx {
public static int add(int a, int b) {
return a + b;
}
}
Compiled to libdevoxx.so, it’s callable from C++. Demonstrations show successful executions, with “Hello Devoxx” printed from Java-originated code.
Contextualized within robotics’ need for low-latency libraries, this bridges languages, allowing Java for logic and C++ for interfaces. Performance evaluations indicate near-native speeds, with startup advantages over JVMs. Implications include simplified maintenance: Java’s safety features reduce bugs in controls, while native compilation ensures compatibility with existing C++ ecosystems.
Performance Analysis and Case Studies
Performance benchmarks compare GraalVM libraries to C++ equivalents: in loops, latencies are comparable, with Java’s GC managed for determinism. Case studies include snake-like inspectors navigating pipes, controlled via Java for path planning.
Analysis reveals GraalVM’s potential in embedded scenarios, where quick compilations (under 5 minutes for small libraries) enable rapid iterations. Safety features, like velocity limits, integrate seamlessly.
Implications: hybrid codebases leverage strengths, enhancing scalability for complex robots like balancing platforms with children.
Future Prospects in Robotic Software Stacks
GraalVM promises polyglot libraries, enabling seamless multi-language calls. HEBI envisions full Java controls, reducing C++ reliance for better productivity.
Challenges: ensuring real-time guarantees in compiled code. Future: broader adoptions in frameworks for robotics.
In conclusion, GraalVM empowers Java in robotics, merging efficiency with developer-friendly tools for innovative systems.
Links:
- Lecture video: https://www.youtube.com/watch?v=md2JFgegN7U
- Florian Enner on LinkedIn: https://www.linkedin.com/in/florian-enner-59b81466/
- Florian Enner on GitHub: https://github.com/ennerf
- HEBI Robotics website: https://www.hebirobotics.com/
[DevoxxBE2025] Behavioral Software Engineering
Lecturer
Mario Fusco is a Senior Principal Software Engineer at Red Hat, where he leads the Drools project, a business rules management system, and contributes to initiatives like LangChain4j. As a Java Champion and open-source advocate, he co-authored “Java 8 in Action” with Raoul-Gabriel Urma and Alan Mycroft, published by Manning. Mario frequently speaks at conferences on topics ranging from functional programming to domain-specific languages.
Abstract
This examination draws parallels between behavioral economics and software engineering, highlighting cognitive biases that distort rational decision-making in technical contexts. It elucidates key heuristics identified by economists like Daniel Kahneman and Amos Tversky, situating them within engineering practices such as benchmarking, tool selection, and architectural choices. Through illustrative examples of performance evaluation flaws and hype-driven adoptions, the narrative scrutinizes methodological influences on project outcomes. Ramifications for collaborative dynamics, innovation barriers, and professional development are explored, proposing mindfulness as a countermeasure to enhance engineering efficacy.
Foundations of Behavioral Economics and Rationality Myths
Classical economic models presupposed fully efficient markets populated by perfectly logical agents, often termed Homo Economicus, who maximize utility through impeccable reasoning. However, pioneering work by psychologists Daniel Kahneman and Amos Tversky in the late 1970s challenged this paradigm, demonstrating that human judgment is riddled with systematic errors. Their prospect theory, for instance, revealed how individuals weigh losses more heavily than equivalent gains, leading to irrational risk aversion or seeking behaviors. This laid the groundwork for behavioral economics, which integrates psychological insights into economic analysis to explain deviations from predicted rational conduct.
In software engineering, a parallel illusion persists: the notion of the “Engeen,” an idealized practitioner who approaches problems with unerring logic and objectivity. Yet, engineers are susceptible to the same mental shortcuts that Kahneman and Tversky cataloged. These heuristics, evolved for quick survival decisions in ancestral environments, often mislead in modern technical scenarios. For example, the anchoring effect—where initial information disproportionately influences subsequent judgments—can skew performance assessments. An engineer might fixate on a preliminary benchmark result, overlooking confounding variables like hardware variability or suboptimal test conditions.
The availability bias compounds this, prioritizing readily recalled information over comprehensive data. If recent experiences involve a particular technology failing, an engineer might unduly favor alternatives, even if statistical evidence suggests otherwise. Contextualized within the rapid evolution of software tools, these biases amplify during hype cycles, where media amplification creates illusory consensus. Implications extend to resource allocation: projects may pursue fashionable solutions, diverting efforts from proven, albeit less glamorous, approaches.
Heuristics in Performance Evaluation and Tool Adoption
Performance benchmarking exemplifies how cognitive shortcuts undermine objective analysis. The availability heuristic leads engineers to overemphasize memorable failures, such as a vivid recollection of a slow database query, while discounting broader datasets. This can result in premature optimizations or misguided architectural pivots. Similarly, anchoring occurs when initial metrics set unrealistic expectations; a prototype’s speed on high-end hardware might bias perceptions of production viability.
Tool adoption is equally fraught. The pro-innovation bias fosters an uncritical embrace of novel technologies, often without rigorous evaluation. Engineers might adopt container orchestration systems like Kubernetes for simple applications, incurring unnecessary complexity. The bandwagon effect reinforces this, as perceived peer adoption creates social proof, echoing Tversky’s work on conformity under uncertainty.
The not-invented-here syndrome further distorts choices, prompting reinvention of wheels due to overconfidence in proprietary solutions. Framing effects alter problem-solving: the same requirement, phrased differently—e.g., “build a scalable service” versus “optimize for cost”—yields divergent designs. Examples from practice include teams favoring microservices for “scalability” when monolithic structures suffice, driven by availability of success stories from tech giants.
Analysis reveals these heuristics degrade quality: biased evaluations lead to inefficient code, while hype-driven adoptions inflate maintenance costs. Implications urge structured methodologies, such as A/B testing or peer reviews, to counteract intuitive pitfalls.
Biases in Collaborative and Organizational Contexts
Team interactions amplify individual biases, creating collective delusions. The curse of knowledge hinders communication: experts assume shared understanding, leading to ambiguous requirements or overlooked edge cases. Hyperbolic discounting prioritizes immediate deliverables over long-term maintainability, accruing technical debt.
Organizational politics exacerbate these: non-technical leaders impose decisions, as in mandating unproven tools based on superficial appeal. Sunk cost fallacy sustains failing projects, ignoring opportunity costs. Dunning-Kruger effect, where incompetence breeds overconfidence, manifests in unqualified critiques of sound engineering.
Confirmation bias selectively affirms preconceptions, dismissing contradictory evidence. In code reviews, this might involve defending flawed implementations by highlighting partial successes. Contextualized within agile methodologies, these biases undermine iterative improvements, fostering resistance to refactoring.
Implications for dynamics: eroded trust hampers collaboration, reducing innovation. Analysis suggests diverse teams dilute biases, as varied perspectives challenge assumptions.
Strategies to Mitigate Biases in Engineering Practices
Mitigation begins with awareness: educating on Kahneman’s System 1 (intuitive) versus System 2 (deliberative) thinking encourages reflective pauses. Structured decision frameworks, like weighted scoring for tool selection, counteract anchoring and availability.
For performance, blind testing—evaluating without preconceptions—promotes objectivity. Debiasing techniques, such as devil’s advocacy, challenge bandwagon tendencies. Organizational interventions include bias training and diverse hiring to foster balanced views.
In practice, adopting evidence-based approaches—rigorous benchmarking protocols—enhances outcomes. Implications: mindful engineering boosts efficiency, reducing rework. Future research could quantify bias impacts via metrics like defect rates.
In essence, recognizing human frailties transforms engineering from intuitive art to disciplined science, yielding superior software.
Links:
- Lecture video: https://www.youtube.com/watch?v=Aa2Zn8WFJrI
- Mario Fusco on LinkedIn: https://www.linkedin.com/in/mariofusco/
- Mario Fusco on Twitter/X: https://twitter.com/mariofusco
- Red Hat website: https://www.redhat.com/
[DevoxxBE2025] Virtual Threads, Structured Concurrency, and Scoped Values: Putting It All Together
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/
[DevoxxBE2025] Live Coding The Hive: Building a Microservices-Ready Modular Monolith
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/
[DevoxxBE2025] Finally, Final Means Final: A Deep Dive into Field Immutability in Java
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/
[DevoxxBE2025] Your Code Base as a Crime Scene
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/
[DevoxxBE2025] Spring Boot: Chapter 4
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/