Jonathan Lalou's Blog

Posts Tagged ‘SpringBoot’

[VoxxedDaysBucharest2026] Building a Sarcastic, Agentic Pair Programmer: Alexander Chatzizacharias on Crafting Playful LLM Workflows

Lecturer

Alexander Chatzizacharias is a software engineer at JDriven, a specialized consultancy in the Netherlands focused on JVM technologies and modern software development practices. With a unique background blending Dutch and Greek influences and a keen interest in game studies, Alexander brings creativity and playful thinking to technical challenges. He frequently speaks on topics including Java, Spring Boot, AI applications, and innovative development workflows.

Abstract

As mainstream AI coding assistants converge toward similar polished but somewhat generic experiences, Alexander Chatzizacharias demonstrates how to build a highly personalized, characterful AI pair programmer named “Pip.” Inspired by interactions with a sarcastic colleague named Ricardo, Pip incorporates personality through vectorized Slack history, utilizes Spring Boot and Kotlin, runs entirely locally with Qwen models via Ollama, and employs sophisticated workflows, multi-vector RAG, and the Model Context Protocol (MCP) to create delightful and productive assistance while addressing challenges like non-determinism and model drift.

The Homogenization of AI Assistants and the Quest for Personality

Alexander observes that leading AI coding tools have converged on remarkably similar chat-based interfaces and interaction patterns, largely influenced by OpenAI’s design choices. While incremental improvements continue, the overall experience feels increasingly uniform. This observation inspired the creation of Pip — an intentionally quirky, sarcastic AI pair programmer that injects personality drawn from real colleague interactions.

By processing Slack conversation history into vector embeddings stored in Qdrant, Pip can retrieve and emulate Ricardo’s characteristic sarcastic tone, witty retorts, and playful threats (such as threatening to delete poorly written code). This transforms the assistant from a neutral tool into a more engaging, human-like collaborator that questions unclear requirements, offers humorous feedback, and makes the development process more enjoyable.

Technical Architecture: Workflows, Agents, and Local Execution

Pip is implemented as a Spring Boot application written in Kotlin, with an IntelliJ IDEA plugin providing the frontend interface. Everything runs locally to maintain privacy and control: Qwen 3.5 models served through Ollama handle the language tasks.

Rather than pursuing fully autonomous agents, Alexander favors structured workflows that provide greater determinism and reliability — attributes particularly valued in enterprise environments. A categorization agent, functioning as an LLM-as-Judge, routes incoming queries to appropriate specialized handlers. Each handler uses carefully crafted system prompts derived from Slack history to consistently embody the desired personality traits.

The architecture incorporates multiple specialized agents for response generation, sophisticated RAG pipelines leveraging both dense and sparse vector representations with ColBERT reranking for improved retrieval quality, and integration with the Model Context Protocol (MCP) for tool usage such as playing music or generating memes when appropriate.

RAG, Tools, and the Challenges of Non-Determinism

Retrieval-Augmented Generation forms a cornerstone of Pip’s capabilities, dynamically pulling relevant context to overcome the inherent token limitations of even advanced models. Multi-vector search strategies combine semantic understanding with keyword precision for more reliable information retrieval from project documentation, codebases, and conversation history.

Tool integration via MCP enables rich interactions but introduces additional complexity due to the non-deterministic nature of local models. Alexander discusses practical challenges including prompt sensitivity to model updates (“model locking” strategies), the art of prompt engineering which he likens to “vibe checking,” and the necessity of implementing guardrails to maintain appropriate behavior boundaries.

Implications for Future AI Development

Alexander encourages attendees to experiment with building personalized, domain-specific AI assistants using accessible open-source tools. While acknowledging the increasing commercialization of AI, he emphasizes the current window of opportunity for creative, playful implementations that enhance both productivity and developer satisfaction.

Pip serves as an inspiring example of how thoughtful combination of RAG techniques, vector databases, workflow orchestration, and personality injection can create AI tools that feel genuinely collaborative rather than merely functional.

Links:

Posted in en-US | Tags: AgenticAI, AI, AlexanderChatzizacharias, Java, Kotlin, LLM, MCP, PairProgramming, Qdrant, Qwen, RAG, SpringBoot, VectorDatabase, VoxxedDaysBucharest2026 | No Comments »

[DevoxxGR2026] Bootiful Spring Boot 4: Exploring the Latest Advancements with Java 25

Author: Jonathan Lalou

Lecturer
Josh Long is a Spring Developer Advocate at VMware, widely recognized as one of the most prominent voices in the Spring ecosystem. Known affectionately as “Mr. Spring,” he is the author of numerous books and a prolific speaker who travels the globe sharing insights on modern Java development. Long co-hosts the “Coffee with a Java Champion” YouTube channel and continues to champion practical, production-ready Spring applications.

Abstract
In this engaging session at Devoxx Greece 2026, Josh Long showcases the transformative capabilities of Spring Boot 4 alongside Java 25. Through live coding of a dog adoption service, he demonstrates powerful new features including virtual threads, API versioning, modular architecture with Spring Modulith, resilient patterns, and seamless integration with AI capabilities. The presentation highlights how the Spring ecosystem empowers developers to build scalable, observable, secure, and intelligent applications with remarkable efficiency.

Java 25 and the Evolution of Spring Boot 4

Spring Boot 4 represents a significant generational leap, aligned with Spring Framework 7. Long emphasizes the decomposition of auto-configuration, resulting in leaner classpaths and faster startup times. Java 25 introduces compelling enhancements, most notably the ability to run simple applications with a single void main() method, effectively delivering the first truly elegant Java scripting experience.

These advancements set the stage for building modern, efficient services that leverage the full power of the JVM while maintaining developer productivity.

Building a Modular Dog Adoption Service

Long begins with a practical example: a service to help adopt dogs. Using Spring Initializr, he configures a project with PostgreSQL, Spring Data JDBC, web support, security, observability through OpenTelemetry and Actuator, and development tools.

The application employs a clean, feature-oriented package structure rather than traditional layered architecture. Records simplify domain modeling, while Spring Data repositories provide type-safe data access with compile-time query generation via AOT processing—beneficial for both JVM and native image deployments.

API Versioning and Resilience Features

To handle evolving requirements, Long demonstrates Spring’s new API versioning capabilities. Multiple endpoint versions coexist, with sensible defaults and header-based selection, ensuring backward compatibility.

Resilience4j integration showcases retryable methods and circuit breakers. Long simulates downstream failures to illustrate automatic recovery, highlighting how declarative resilience patterns simplify robust service design.

Modular Architecture with Spring Modulith

A standout demonstration involves refactoring into feature modules—dogs, cats, and veterinary services—using Spring Modulith. This enforces architectural boundaries at compile time while supporting event-driven communication between modules through ApplicationModuleListener and the outbox pattern for reliable, eventually consistent inter-module interactions.

The framework automatically generates documentation, C4 architecture diagrams, and verifies module dependencies, bridging the gap between intended design and runtime reality.

Security and Production Readiness

Security configuration leverages Spring Security 7’s additive customizers, preserving sensible defaults while enabling features like one-time token login and password migration. Passkeys (WebAuthn) integration provides passwordless authentication using biometrics, representing a significant usability and security improvement.

Observability is built-in through Actuator and OpenTelemetry, with production considerations like resource limits addressed from the start.

Integrating AI Capabilities

Long concludes by incorporating Spring AI 2.0, demonstrating how to augment the application with intelligent assistants. Using skills and tool calling, the service can answer domain-specific questions about dogs and cats, showcasing the natural convergence of Spring Boot with modern AI workflows.

The Bright Future of Java and Spring Development

Throughout the session, Long reinforces that the combination of Java’s efficiency, Spring’s comprehensive ecosystem, and new generative AI tools positions developers exceptionally well. Despite industry hype cycles, the fundamentals of solid engineering—modularity, resilience, observability, and security—remain paramount.

Spring Boot 4 and Java 25 deliver the tools necessary to build systems that are faster, more scalable, more maintainable, and more intelligent than ever before.

Links:

Posted in en-US | Tags: DevoxxGR2026, Java25, JoshLong, Modulith, Resilience, SpringAI, SpringBoot, SpringFramework | No Comments »

[SpringIO2025] Panta rhei: runtime configuration updates with Spring Boot by Joris Kuipers

Author: Jonathan Lalou

Lecturer

Joris Kuipers is the CTO and hands-on architect at Trifork Amsterdam, with 25 years of experience in software engineering, enterprise Java consulting, and architecture. Specializing in Spring Boot, he focuses on observability, JSON processing, and dynamic configuration. Kuipers is an active speaker at conferences like Spring I/O, contributing insights on production-ready applications and performance optimizations.

Abstract

This article explores Spring’s mechanisms for dynamic configuration reloads in Boot applications, enabling runtime updates without restarts. It delineates reloadable elements like logging configurations, @ConfigurationProperties beans, and @RefreshScope-annotated components. The analysis covers trigger mechanisms, supported property sources, and considerations for production deployment, including Kubernetes integrations and potential pitfalls.

Foundations of Dynamic Configuration in Spring

Configuration in Spring Boot applications is environment-specific, allowing a single build to adapt via external property sources like files, classpath resources, or remote servers. Traditionally read at startup, changes necessitate restarts, leading to downtime, loss of in-memory state (e.g., caches), and JVM warm-up delays, which can extend from seconds to hours for complex integrations.

Spring Cloud Context introduces reload capabilities, exposing writable actuator endpoints for ephemeral updates and refresh triggers for persistent sources. Posting to the /actuator/env endpoint rebinds @ConfigurationProperties beans and updates logging levels, though changes revert on restart. The /actuator/refresh endpoint, when triggered, reloads external configurations, rebinding properties without full context restarts.

Demo applications illustrate this: a simple MVC controller injects mutable and immutable @ConfigurationProperties classes, demonstrating value updates via getters to ensure visibility.

Trigger Mechanisms and Reloadable Components

Reloads can be manual (POST to /actuator/refresh) or automated via change detection in property sources. @ConfigurationProperties beans rebind automatically, but direct field access in mutable classes may cache stale values—always use getters.

@RefreshScope proxies beans, destroying and recreating them on refresh, useful for stateful components like data sources. However, it incurs overhead and requires careful management to avoid disrupting dependencies.

Logging configurations reload dynamically, altering levels without restarts. @Value annotations, while injectable, do not rebind automatically unless scoped.

Code for enabling refresh:

@SpringBootApplication
@RefreshScope  // Optional for specific beans
public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

Supported Property Sources and Kubernetes Integrations

Property sources vary in reload support: file-based (e.g., application.properties) require manual triggers, while remote sources like Consul enable automatic detection via polling (e.g., every 30 seconds).

In Kubernetes, ConfigMaps and Secrets mount as files or environment variables. Spring Cloud Kubernetes Config Reload detects changes, triggering refreshes. Configuration involves enabling reload mode (e.g., polling) and setting intervals.

Example properties:

spring.cloud.kubernetes.config.enabled=true
spring.cloud.kubernetes.reload.enabled=true
spring.cloud.kubernetes.reload.mode=polling
spring.cloud.kubernetes.reload.period=30s

Delays in propagation (e.g., 30+ seconds) necessitate tuning to avoid partial updates.

Practical Considerations and Best Practices

Dynamic reloads suit credential rotations or feature flags but require securing actuators to prevent denial-of-service. Avoid Hikari for refresh-scoped data sources due to connection issues; alternatives like Tomcat JDBC work better.

CRaC (Checkpoint/Restore) combines with reloads for fast startups with dynamic configs, but GraalVM is unsupported. Validate via /actuator/env and /actuator/configprops; test for binding errors.

In conclusion, runtime updates enhance availability and efficiency, demanding rigorous testing to mitigate risks like incomplete propagations.

Links:

Posted in en-US | Tags: DynamicConfiguration, JorisKuipers, KubernetesConfig, RuntimeReloads, SpringBoot, SpringIO2025 | No Comments »

[MunchenJUG] Reliability in Enterprise Software: A Critical Analysis of Automated Testing in Spring Boot Ecosystems (27/Oct/2025)

Author: Jonathan Lalou

Lecturer

Philip Riecks is an independent software consultant and educator specializing in Java, Spring Boot, and cloud-native architectures. With over seven years of professional experience in the software industry, Philip has established himself as a prominent voice in the Java ecosystem through his platform, Testing Java Applications Made Simple. He is a co-author of the influential technical book Stratospheric: From Zero to Production with Spring Boot and AWS, which bridges the gap between local development and production-ready cloud deployments. In addition to his consulting work, he produces extensive educational content via his blog and YouTube channel, focusing on demystifying complex testing patterns for enterprise developers.

Abstract

In the contemporary landscape of rapid software delivery, automated testing serves as the primary safeguard for application reliability and maintainability. This article explores the methodologies for demystifying testing within the Spring Boot framework, moving beyond superficial unit tests toward a comprehensive strategy that encompasses integration and slice testing. By analyzing the “Developer’s Dilemma”—the friction between speed of delivery and the confidence provided by a robust test suite—this analysis identifies key innovations such as the “Testing Pyramid” and specialized Spring Boot test slices. The discussion further examines the technical implications of external dependency management through tools like Testcontainers and WireMock, advocating for a holistic approach that treats test code with the same rigor as production logic.

The Paradigm Shift in Testing Methodology

Traditional software development often relegated testing to a secondary phase, frequently outsourced to separate quality assurance departments. However, the rise of DevOps and continuous integration has necessitated a shift toward “test-driven” or “test-enabled” development. Philip Riecks identifies that the primary challenge for developers is not the lack of tools, but the lack of a clear strategy. Testing is often perceived as a bottleneck rather than an accelerator.

The methodology proposed focuses on the Testing Pyramid, which prioritizes a high volume of fast, isolated unit tests at the base, followed by a smaller number of integration tests, and a minimal set of end-to-end (E2E) tests at the apex. The innovation in Spring Boot testing lies in its ability to provide “Slice Testing,” allowing developers to load only specific parts of the application context (e.g., the web layer or the data access layer) rather than the entire infrastructure. This approach significantly reduces test execution time while maintaining high fidelity.

Architectural Slicing and Context Management

One of the most powerful features of the Spring Boot ecosystem is its refined support for slice testing via annotations. This allows for an analytical approach to testing where the scope of the test is strictly defined by the architectural layer under scrutiny.

Web Layer Testing: Using @WebMvcTest, developers can test REST controllers without launching a full HTTP server. This slice provides a mocked environment where the web infrastructure is active, but business services are replaced by mocks (e.g., using @MockBean).
Data Access Testing: The @DataJpaTest annotation provides a specialized environment for testing JPA repositories. It typically uses an in-memory database by default, ensuring that database interactions are verified without the overhead of a production-grade database.
JSON Serialization: @JsonTest isolates the serialization and deserialization logic, ensuring that data structures correctly map to their JSON representations.

This granular control prevents “Context Bloat,” where tests become slow and brittle due to the unnecessary loading of the entire application environment.

Code Sample: A Specialized Controller Test Slice

@WebMvcTest(UserRegistrationController.class)
class UserRegistrationControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @MockBean
    private UserRegistrationService registrationService;

    @Test
    void shouldRegisterUserSuccessfully() throws Exception {
        mockMvc.perform(post("/api/users")
                .contentType(MediaType.APPLICATION_JSON)
                .content("{\"username\": \"priecks\", \"email\": \"philip@example.com\"}"))
                .andExpect(status().isCreated());
    }
}

Managing External Dependencies: Testcontainers and WireMock

A significant hurdle in integration testing is the reliance on external systems such as databases, message brokers, or third-party APIs. Philip emphasizes the move away from “In-Memory” databases (like H2) for testing production-grade applications, citing the risk of “Environment Parity” issues where H2 behaves differently than a production PostgreSQL instance.

The integration of Testcontainers allows developers to spin up actual Docker instances of their production infrastructure during the test lifecycle. This ensures that the code is tested against the exact same database engine used in production. Similarly, WireMock is utilized to simulate external HTTP APIs, allowing for the verification of fault-tolerance mechanisms like retries and circuit breakers without depending on the availability of the actual external service.

Consequences of Testing on Long-term Maintainability

The implications of a robust testing strategy extend far beyond immediate bug detection. A well-tested codebase enables fearless refactoring. When developers have a “safety net” of automated tests, they can update dependencies, optimize algorithms, or redesign components with the confidence that existing functionality remains intact.

Furthermore, Philip argues that the responsibility for quality must lie with the engineer who writes the code. In an “On-Call” culture, the developer who builds the system also runs it. This ownership model, supported by automated testing, transforms software engineering from a process of “handing over” code to one of “carefully crafting” resilient systems.

Conclusion

Demystifying Spring Boot testing requires a transition from viewing tests as a chore to seeing them as a fundamental engineering discipline. By leveraging architectural slices, managing dependencies with Testcontainers, and adhering to the Testing Pyramid, developers can build applications that are not only functional but also sustainable. The ultimate goal is to reach a state where testing provides joy through the confidence it instills, ensuring that the software remains a robust asset for the enterprise rather than a source of technical debt.

Links:

Posted in en-US | Tags: architecture, CleanCode, devops, Java, JUnit, MunchenJUG, PhilipRiecks, SoftwareTesting, SpringBoot, Testcontainers | No Comments »

[DevoxxBE2025] Virtual Threads, Structured Concurrency, and Scoped Values: Putting It All Together

Author: Jonathan Lalou

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/

Posted in en-US | Tags: BalkrishnaRawool, DevoxxBE2025, INGBank, JavaParallelism, ProjectLoom, ScopedValues, SpringBoot, StructuredConcurrency, VirtualThreads | No Comments »

[DevoxxFR2025] Boosting Java Application Startup Time: JVM and Framework Optimizations

Author: Jonathan Lalou

In the world of modern application deployment, particularly in cloud-native and microservice architectures, fast startup time is a crucial factor impacting scalability, resilience, and cost efficiency. Slow-starting applications can delay deployments, hinder auto-scaling responsiveness, and consume resources unnecessarily. Olivier Bourgain, in his presentation, delved into strategies for significantly accelerating the startup time of Java applications, focusing on optimizations at both the Java Virtual Machine (JVM) level and within popular frameworks like Spring Boot. He explored techniques ranging from garbage collection tuning to leveraging emerging technologies like OpenJDK’s Project Leyden and Spring AOT (Ahead-of-Time Compilation) to make Java applications lighter, faster, and more efficient from the moment they start.

The Importance of Fast Startup

Olivier began by explaining why fast startup time matters in modern environments. In microservices architectures, applications are frequently started and stopped as part of scaling events, deployments, or rolling updates. A slow startup adds to the time it takes to scale up to handle increased load, potentially leading to performance degradation or service unavailability. In serverless or function-as-a-service environments, cold starts (the time it takes for an idle instance to become ready) are directly impacted by application startup time, affecting latency and user experience. Faster startup also improves developer productivity by reducing the waiting time during local development and testing cycles. Olivier emphasized that optimizing startup time is no longer just a minor optimization but a fundamental requirement for efficient cloud-native deployments.

JVM and Garbage Collection Optimizations

Optimizing the JVM configuration and understanding garbage collection behavior are foundational steps in improving Java application startup. Olivier discussed how different garbage collectors (like G1, Parallel, or ZGC) can impact startup time and memory usage. Tuning JVM arguments related to heap size, garbage collection pauses, and just-in-time (JIT) compilation tiers can influence how quickly the application becomes responsive. While JIT compilation is crucial for long-term performance, it can introduce startup overhead as the JVM analyzes and optimizes code during initial execution. Techniques like Class Data Sharing (CDS) were mentioned as a way to reduce startup time by sharing pre-processed class metadata between multiple JVM instances. Olivier provided practical tips and configurations for optimizing JVM settings specifically for faster startup, balancing it with overall application performance.

Framework Optimizations: Spring Boot and Beyond

Popular frameworks like Spring Boot, while providing immense productivity benefits, can sometimes contribute to longer startup times due to their extensive features and reliance on reflection and classpath scanning during initialization. Olivier explored strategies within the Spring ecosystem and other frameworks to mitigate this. He highlighted Spring AOT (Ahead-of-Time Compilation) as a transformative technology that analyzes the application at build time and generates optimized code and configuration, reducing the work the JVM needs to do at runtime. This can significantly decrease startup time and memory footprint, making Spring Boot applications more suitable for resource-constrained environments and serverless deployments. Project Leyden in OpenJDK, aiming to enable static images and further AOT compilation for Java, was also discussed as a future direction for improving startup performance at the language level. Olivier demonstrated how applying these framework-specific optimizations and leveraging AOT compilation can have a dramatic impact on the startup speed of Java applications, making them competitive with applications written in languages traditionally known for faster startup.

Links:

Olivier Bourgain: https://www.linkedin.com/in/olivier-bourgain/
Mirakl: https://www.mirakl.com/
Spring Boot: https://spring.io/projects/spring-boot
OpenJDK Project Leyden: https://openjdk.org/projects/leyden/
Devoxx France LinkedIn: https://www.linkedin.com/company/devoxx-france/
Devoxx France Bluesky: https://bsky.app/profile/devoxx.fr
Devoxx France Website: https://www.devoxx.fr/

Posted in en-US | Tags: AOT, CloudNative, DevoxxFR2025, GarbageCollection, Java, JVM, Microservices, Mirakl, OlivierBourgain, Performance, ProjectLeyden, SpringBoot, StartupTime | No Comments »

Java/Spring Troubleshooting: From Memory Leaks to Database Bottlenecks

Author: Jonathan Lalou

Practical strategies and hands-on tips for diagnosing and fixing performance issues in production Java applications.

1) Approaching Memory Leaks

Memory leaks in Java often manifest as OutOfMemoryError exceptions or rising heap usage visible in monitoring dashboards. My approach:

Reproduce in staging: Apply the same traffic profile (e.g., JMeter load test).

Collect a heap dump:

jmap -dump:format=b,file=heap.hprof <PID>

Analyze with tools: Eclipse MAT, VisualVM, or YourKit to detect uncollected references.
Fix common causes:
- Unclosed streams or ResultSets.
- Static collections holding references.
- Caches without eviction policies (e.g., replace HashMap with Caffeine).

2) Profiling and Fixing High CPU Usage

High CPU can stem from tight loops, inefficient queries, or excessive logging.

Step 1: Sample threads
```
jstack <PID> > thread-dump.txt
```
Identify “hot” threads consuming CPU.

Step 2: Profile with async profilers like async-profiler or Java Flight Recorder.

java -XX:StartFlightRecording=duration=60s,filename=recording.jfr -jar app.jar

Step 3: Refactor:
- Replace String concatenation in loops with StringBuilder.
- Optimize regex (use Pattern reuse instead of String.matches()).
- Review logging level (DEBUG inside loops is expensive).

3) Tuning GC for Low-Latency Services

Garbage collection (GC) can cause pauses. For trading, gaming, or API services, tuning matters:

Choose the right collector:
- G1GC for balanced throughput and latency (default in recent JDKs).
- ZGC or Shenandoah for ultra-low latency workloads (<10ms pauses).

Sample configs:

-XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+ParallelRefProcEnabled

Monitor GC logs with GC Toolkit or Grafana dashboards.

4) Handling Database Bottlenecks

Spring apps often hit bottlenecks in DB queries rather than CPU.

Enable SQL logging: in application.properties
```
spring.jpa.show-sql=true
```
Profile queries: Use p6spy or database AWR reports.
Fixes:
- Add missing indexes (EXPLAIN ANALYZE is your friend).
- Batch inserts (saveAll() in Spring Data with hibernate.jdbc.batch_size).
- Introduce caching (Spring Cache, Redis) for hot reads.
- Use connection pools like HikariCP with tuned settings:
```
spring.datasource.hikari.maximum-pool-size=30
```

Posted in en-US | Tags: GC, MemoryLeaks, Profiling, SpringBoot, SRE | No Comments »

Efficient Inter-Service Communication with Feign and Spring Cloud in Multi-Instance Microservices

Author: Jonathan Lalou

In a world where systems are becoming increasingly distributed and cloud-native, microservices have emerged as the de facto architecture. But as we scale
microservices horizontally—running multiple instances for each service—one of the biggest challenges becomes inter-service communication.

How do we ensure that our services talk to each other reliably, efficiently, and in a way that’s resilient to failures?

Welcome to the world of Feign and Spring Cloud.

The Challenge: Multi-Instance Microservices

Imagine you have a user-service that needs to talk to an order-service, and your order-service runs 5 instances behind a
service registry like Eureka. Hardcoding URLs? That’s brittle. Manual load balancing? Not scalable.

You need:

Service discovery to dynamically resolve where to send the request
Load balancing across instances
Resilience for timeouts, retries, and fallbacks
Clean, maintainable code that developers love

The Solution: Feign + Spring Cloud

OpenFeign is a declarative web client. Think of it as a smart HTTP client where you only define interfaces — no more boilerplate REST calls.

When combined with Spring Cloud, Feign becomes a first-class citizen in a dynamic, scalable microservices ecosystem.

✅ Features at a Glance:

Declarative REST client
Automatic service discovery (Eureka, Consul)
Client-side load balancing (Spring Cloud LoadBalancer)
Integration with Resilience4j for circuit breaking
Easy integration with Spring Boot config and observability tools

Step-by-Step Setup

1. Add Dependencies

[xml][/xml]

If using Eureka:

[xml][/xml]

2. Enable Feign Clients

In your main Spring Boot application class:

[java]@SpringBootApplication
@EnableFeignClients
public <span>class <span>UserServiceApplication { … }
[/java]

3. Define Your Feign Interface

[java]
@FeignClient(name = "order-service")
public interface OrderClient { @GetMapping("/orders/{id}")
OrderDTO getOrder(@PathVariable("id") Long id); }
[/java]

Spring will automatically:

Register this as a bean
Resolve order-service from Eureka
Load-balance across all its instances

4. Add Resilience with Fallbacks

You can configure a fallback to handle failures gracefully:

[java]

@FeignClient(name = "order-service", fallback = OrderClientFallback.class)
public interface OrderClient {
@GetMapping("/orders/{id}") OrderDTO getOrder(@PathVariable Long id);
}[/java]

The fallback:

[java]

@Component
public class OrderClientFallback implements OrderClient {
@Override public OrderDTO getOrder(Long id) {
return new OrderDTO(id, "Fallback Order", LocalDate.now());
}
}[/java]

⚙️ Configuration Tweaks

Customize Feign timeouts in application.yml:

[yml]

feign:

client:

config:

default:

connectTimeout:3000

readTimeout:500

[/yml]

Enable retry:

[xml]
feign:
client:
config:
default:
retryer:
maxAttempts: 3
period: 1000
maxPeriod: 2000
[/xml]

What Happens Behind the Scenes?

When user-service calls order-service:

Spring Cloud uses Eureka to resolve all instances of order-service.
Spring Cloud LoadBalancer picks an instance using round-robin (or your chosen strategy).
Feign sends the HTTP request to that instance.
If it fails, Resilience4j (or your fallback) handles it gracefully.

Observability & Debugging

Use Spring Boot Actuator to expose Feign metrics:

[xml]

<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency[/xml]

And tools like Spring Cloud Sleuth + Zipkin for distributed tracing across Feign calls.

Beyond the Basics

To go even further:

Integrate with Spring Cloud Gateway for API routing and external access.
Use Spring Cloud Config Server to centralize configuration across environments.
Secure Feign calls with OAuth2 via Spring Security and OpenID Connect.

✨ Final Thoughts

Using Feign with Spring Cloud transforms service-to-service communication from a tedious, error-prone task into a clean, scalable, and cloud-native solution.
Whether you’re scaling services across zones or deploying in Kubernetes, Feign ensures your services communicate intelligently and resiliently.

Posted in en-US | Tags: DistributedSystems, FeignClient, Java, Microservices, SpringBoot, SpringCloud | No Comments »

SpringBatch: How to have different schedules, per environment, for instance: keep the fixedDelay=60000 in prod, but schedule with a Cron expression in local dev?

Author: Jonathan Lalou

Case

In SpringBatch, a batch is scheduled in a bean JobScheduler with

[java]
@Scheduled(fixedDelay = 60000)
void doSomeThing(){…}
[/java]

.
How to have different schedules, per environment, for instance: keep the fixedDelay=60000 in prod, but schedule with a Cron expression in local dev?

Solution

Add this block to the <JobScheduler:

[java]
@Value("${jobScheduler.scheduling.enabled:true}")
private boolean schedulingEnabled;

@Value("${jobScheduler.scheduling.type:fixedDelay}")
private String scheduleType;

@Value("${jobScheduler.scheduling.fixedDelay:60000}")
private long fixedDelay;

@Value("${jobScheduler.scheduling.initialDelay:0}")
private long initialDelay;

@Value("${jobScheduler.scheduling.cron:}")
private String cronExpression;

@Scheduled(fixedDelayString = "${jobScheduler.scheduling.fixedDelay:60000}", initialDelayString = "${jobScheduler.scheduling.initialDelay:0}")
@ConditionalOnProperty(name = "jobScheduler.scheduling.type", havingValue = "fixedDelay")
public void scheduleFixedDelay() throws Exception {
if ("fixedDelay".equals(scheduleType) || "initialDelayFixedDelay".equals(scheduleType)) {
doSomething();
}
}

@Scheduled(cron = "${jobScheduler.scheduling.cron:0 0 1 * * ?}")
@ConditionalOnProperty(name = "jobScheduler.scheduling.type", havingValue = "cron", matchIfMissing = false)
public void scheduleCron() throws Exception {
if ("cron".equals(scheduleType)) {
doSomething(); }
}
[/java]

In application.yml, add:

[xml]
jobScheduler:
# noinspection GrazieInspection
scheduling:
enabled: true
type: fixedDelay
fixedDelay: 60000
initialDelay: 0
cron: 0 0 1 31 2 ? # every 31st of February… which means: never
[/xml]

(note the cron expression: leaving it empty may prevent SpringBoot from starting)

In application.yml, add:

[xml]
jobScheduler:
# noinspection GrazieInspection
scheduling:
type: cron
cron: 0 0 1 * * ?
[/xml]

It should work now ;-).

Posted in en-US | Tags: SpringBatch, SpringBoot | No Comments »

[DevoxxUK2024] Breaking AI: Live Coding and Hacking Applications with Generative AI by Simon Maple and Brian Vermeer

Author: Jonathan Lalou

Simon Maple and Brian Vermeer, both seasoned developer advocates with extensive experience at Snyk and other tech firms, delivered an electrifying live coding session at DevoxxUK2024, exploring the double-edged sword of generative AI in software development. Simon, recently transitioned to a stealth-mode startup, and Brian, a current Snyk advocate, demonstrate how tools like GitHub Copilot and ChatGPT can accelerate coding velocity while introducing significant security risks. Through a live-coded Spring Boot coffee shop application, they expose vulnerabilities such as SQL injection, directory traversal, and cross-site scripting, emphasizing the need for rigorous validation and security practices. Their engaging, demo-driven approach underscores the balance between innovation and caution, offering developers actionable insights for leveraging AI safely.

Accelerating Development with Generative AI

Simon and Brian kick off by highlighting the productivity boost offered by generative AI tools, citing studies that suggest a 55% increase in developer efficiency and a 27% higher likelihood of meeting project goals. They build a Spring Boot application with a Thymeleaf front end, using Copilot to generate a homepage with a banner and product table. The process showcases AI’s ability to rapidly produce code snippets, such as HTML fragments, based on minimal prompts. However, they caution that this speed comes with risks, as AI often prioritizes completion over correctness, potentially embedding vulnerabilities. Their live demo illustrates how Copilot’s suggestions evolve with context, but also how developers must critically evaluate outputs to ensure functionality and security.

Exposing SQL Injection Vulnerabilities

The duo dives into a search functionality for their coffee shop application, where Copilot generates a query to filter products by name or description. However, the initial code concatenates user input directly into an SQL query, creating a classic SQL injection vulnerability. Brian demonstrates an exploit by injecting malicious input to set product prices to zero, highlighting how unchecked AI-generated code can compromise a system. They then refactor the code using prepared statements, showing how parameterization separates user input from the query execution plan, effectively neutralizing the vulnerability. This example underscores the importance of understanding AI outputs and applying secure coding practices, as tools like Copilot may not inherently prioritize security.

Mitigating Directory Traversal Risks

Next, Simon and Brian tackle a profile picture upload feature, where Copilot generates code to save files to a directory. The initial implementation concatenates user-provided file names with a base path, opening the door to directory traversal attacks. Using Burp Suite, they demonstrate how an attacker could overwrite critical files by manipulating the file name with “../” sequences. To address this, they refine the code to normalize paths, ensuring files remain within the intended directory. The session highlights the limitations of AI in detecting complex vulnerabilities like path traversal, emphasizing the need for developer vigilance and tools like Snyk to catch issues early in the development cycle.

Addressing Cross-Site Scripting Threats

The final vulnerability explored is cross-site scripting (XSS) in a product page feature. The AI-generated code directly embeds user input (product names) into HTML without sanitization, allowing Brian to inject a malicious script that captures session cookies. They demonstrate both reflective and stored XSS, showing how attackers could exploit these to hijack user sessions. While querying ChatGPT for a code review fails to pinpoint the XSS issue, Simon and Brian advocate for using established libraries like Spring Utils for input sanitization. This segment reinforces the necessity of combining AI tools with robust security practices and automated scanning to mitigate risks that AI might overlook.

Balancing Innovation and Security

Throughout the session, Simon and Brian stress that generative AI, while transformative, demands a cautious approach. They liken AI tools to junior developers, capable of producing functional code but requiring oversight to avoid errors or vulnerabilities. Real-world examples, such as a Samsung employee leaking sensitive code via ChatGPT, underscore the risks of blindly trusting AI outputs. They advocate for education, clear guidelines, and security tooling to complement AI-assisted development. By integrating tools like Snyk for vulnerability scanning and fostering a culture of code review, developers can harness AI’s potential while safeguarding their applications against threats.

Links:

Posted in en-US | Tags: BrianVermeer, ChatGPT, Copilot, DevoxxUK2024, GenerativeAI, Security, SimonMaple, Snyk, SpringBoot | No Comments »