GT's Blog

Manually Analyze JFR Files to Find Optimization Targets

2026-08-02T21:57:29.545+01:00

A systematic guide to reading Java Flight Recorder dumps and turning the data into faster startup, lower memory pressure, and higher throughput.

When your Java application takes too long to start or burns too much CPU under load, intuition is a poor compass. Guessing at bottlenecks — "maybe it's the database queries," "maybe we have too many objects to wire up" — leads to wasted effort. You need data.

A profiler is a tool that records what a program is actually doing while it runs. Unlike logs, which tell you only what your application chose to report, a profiler observes the JVM itself — where CPU time goes, what objects get allocated, which methods get compiled, where threads wait, and how memory changes over time. Java Flight Recorder (JFR) is the JVM's built-in profiler, designed to run with very low overhead (typically well under 1–2% with default settings, and still modest with the fuller profile configuration). It captures an extraordinary breadth of telemetry: CPU sampling, allocation profiling, GC behavior, lock contention, I/O activity, class loading, JIT compilation — all from a single recording file. A single .jfr file is a rich forensic trace of what your JVM did during the recording window.

But a JFR file is not a report. It's a dense, binary event log containing over a hundred built-in event types. The skill is knowing which events to extract, how to interpret them, and what optimization they point to.

This post walks through a manual, systematic methodology for analyzing a JFR recording. You can follow along using the JDK's built-in jfr CLI, JDK Mission Control (JMC), or an IDE profiler such as IntelliJ's. The goal is not just to run a tool, but to understand what you're looking at and what to do about it.

1. Capturing a Useful JFR Recording

Before you can analyze anything, you need a good recording. The default JFR configuration captures a minimal set of events. For startup or performance analysis, use the profile setting, which adds allocation sampling and other detail on top of the default:

# Attach to a running JVM
jcmd <PID> JFR.start settings=profile name=startup-analysis

# Wait for the event you care about (startup, request burst, etc.)
# then stop and dump to disk:
jcmd <PID> JFR.stop name=startup-analysis filename=recording.jfr

For startup analysis specifically, pass JFR flags directly to the JVM so recording begins at launch:

java -XX:StartFlightRecording=settings=profile,filename=startup.jfr \
     -jar my-application.jar

Key principle: Record exactly the window you care about. A 30-second recording during startup is far more actionable than a 5-minute recording that mixes startup, steady-state, and idle periods. The metrics become averages over too many phases, and the signal washes out.

A note on warmup: during startup the JVM is doing several expensive things at once — loading and linking classes, compiling hot methods, allocating the objects that make up your object graph, and initializing caches and connection pools. All of that activity is concentrated into a short window, which is exactly why startup recordings look so different from steady-state recordings: heavier class-loading and compilation cost, a burst of allocation, and comparatively little of the request-handling activity you'd see later. Don't be surprised if a startup profile and a steady-state profile of the same application barely resemble each other — they're capturing different phases of the JVM's life, and both are "correct."

2. The Analysis Framework: 12 Dimensions

A JFR recording spans several distinct dimensions of JVM behavior. Each answers a different question about your application. Rather than jumping between them haphazardly, work through them in this order — each section's findings inform the next:

#	Dimension	Key Question
1	CPU Hotspots	Where is CPU time actually being spent?
2	Memory Allocation	What objects are being created, and from where?
3	GC / Heap Timeline	How is the heap growing, and how much time is spent collecting?
4	GC Pause Times	How long are stop-the-world pauses, and which GC phases cause them?
5	Class Loading	How many classes are loaded, and is that excessive?
6	Thread Creation	How many threads are spawned, and by which subsystems?
7	Lock Contention	Where are threads blocking each other?
8	JIT Compilation	How much CPU goes into compiling bytecode, and which methods cost the most?
9	Socket / File I/O	How much I/O is happening, to what, and how long does it wait?
10	CPU Load Timeline	Is the JVM CPU-bound, I/O-bound, or uncontested?
11	Thread Idle / Sleep Time	Which threads are idle or waiting, and for how long?
12	Before/After Comparison	Did your optimization actually help?

Let's walk through each dimension with concrete examples of what to extract, what patterns to look for, and what optimizations each pattern suggests.

3. Dimension 1: CPU Execution Hotspots

JFR does sampling profiling, not instrumentation. Instead of measuring every single method call — which would slow the application down considerably and change the very behavior you're trying to observe — the JVM periodically interrupts each running thread and records what it's doing. If a method shows up in a large share of the samples, it probably consumed a significant amount of CPU time; a method that never shows up may still have run, just not enough (or not at the right moments) to be caught.

Data source: jdk.ExecutionSample events. These are periodic thread samples that capture the full stack trace of a running thread. The sampling interval depends on your recording configuration and JDK version rather than a single fixed number — check the settings file (e.g., profile.jfc) or the recording metadata if you need the exact value for your run. Each sample counts as one "vote" — a method appearing in 500 samples was on-CPU for roughly 500 sampling periods, so treat the resulting time estimate as approximate, not exact.

A limitation worth knowing: sampling profilers can't reliably measure very short-lived methods, because a method can start and finish entirely between two samples and never get caught. A method with only a handful of samples in a large recording isn't necessarily unimportant — but it also isn't necessarily important. Don't over-interpret single-digit sample counts either way; focus your attention on methods with enough samples that the pattern is statistically meaningful.

What to Extract

Using the JDK's jfr CLI:

# Text mode gives full stack traces in a readable format
jfr print --events jdk.ExecutionSample recording.jfr

Each block looks like this:

jdk.ExecutionSample {
  sampledThread = "main" (javaThreadId = 1)
  state = "STATE_RUNNABLE"
  stackTrace = [
    java.lang.ClassLoader.defineClass1(ClassLoader.java:0)     ← LEAF (hottest)
    java.lang.ClassLoader.defineClass(ClassLoader.java:539)
    java.security.SecureClassLoader.defineClass(...)
    java.net.URLClassLoader.defineClass(...)
    java.net.URLClassLoader$1.run(...)
    ...
  ]
}

A quick glossary, since the rest of this post leans on this terminology constantly. A stack trace is the chain of method calls active at a single point in time — each individual call in that chain is a stack frame. Using a simplified example:

main()
 └── loadUsers()
      └── parseJson()
           └── StringBuilder.append()

The root frame is the entry point (main() here). The leaf frame is the innermost, most-recently-called method (StringBuilder.append() here) — it's the one that was actually executing, on the CPU, at the instant the sample was taken.

The leaf frame (index 0 in the JFR output) tells you what is burning CPU. The full stack tells you why — the call chain that led there. Both matter: the same leaf method can appear under very different stacks, and grouping by leaf-only can hide the fact that two unrelated code paths are converging on the same expensive call.

Patterns and What They Mean

Pattern A: ClassLoader.defineClass1 dominates the leaf samples

This means the JVM is spending a large share of its CPU defining classes — reading bytes from JAR files, parsing the classfile format, verifying bytecode, and linking into the runtime. On a cold startup of any JVM application with a non-trivial classpath, this can be a substantial fraction of samples, though the exact share varies widely by application size and JAR count.

Optimization: Use Class Data Sharing (CDS). CDS creates a shared archive containing preprocessed class metadata from a prior run. On later JVM starts, many of those classes can be mapped directly from the archive instead of being repeatedly read from JARs, parsed, verified, and linked from scratch — the expensive work happens once, when the archive is built, rather than on every single startup:
java -XX:ArchiveClassesAtExit=app-cds.jsa -jar my-app.jar
java -XX:SharedArchiveFile=app-cds.jsa -jar my-app.jar
This typically produces a meaningful reduction in class-loading CPU time. Treat any specific percentage as a rough expectation, not a guarantee — measure before/after on your own app (see Dimension 12).

Pattern B: Inflater.inflateBytes high in the stacks

This is JAR decompression overhead. Every JAR entry is typically compressed; reading a class means decompressing it first. The more JARs on your classpath, the more inflation CPU you pay.

Optimization: CDS helps here too — the shared archive stores classes in an already-processed form so they don't need to be decompressed and parsed again on every startup. Also consider trimming unused JARs from your classpath.

Pattern C: Classpath/annotation-scanning code appears prominently

If your application uses a dependency-injection or component-scanning framework (Spring, Micronaut, Quarkus/Jakarta CDI, Guice with classpath scanning, etc.), startup often involves walking the classpath looking for annotated types, reading .class files, and building object-graph or bean metadata from what it finds. In stack traces this typically shows up as framework-internal classpath-scanner or annotation-reader classes.

Optimization: Most DI frameworks offer a way to avoid runtime scanning — build-time indexing (e.g., Spring's context indexer generates a component index at compile time), ahead-of-time processing (Spring AOT, Micronaut and Quarkus both compute much of this at build time by design), or simply scoping the scan to a narrower set of packages instead of the whole classpath. Check your framework's documentation for its specific mechanism.

Pattern D: Constructor.newInstance or Method.invoke appear heavily

This is reflection-driven instantiation. DI containers, ORMs, and serialization libraries (Spring, Hibernate/JPA, Guice, Jackson, and others) commonly use reflection for object creation, proxy generation, and field/property access.

Optimization: Many frameworks offer reflection-reduced or reflection-free code paths for common cases (e.g., Spring AOT, Micronaut's compile-time DI, Quarkus's build-time processing). A more drastic option is GraalVM Native Image, which compiles your application ahead-of-time into a standalone native executable — this eliminates JIT compilation and most runtime class loading entirely, since nearly all of that work happens at build time instead of at every startup. The trade-off: build times are much longer, you generally give up the JIT's runtime, profile-guided optimizations (so peak steady-state throughput can be lower than a warmed-up JVM), and anything relying on dynamic behavior — reflection, dynamic proxies, resources loaded by name, JNI — needs to be explicitly declared in build-time configuration, since native image can't discover it at runtime the way the JVM can.

Pattern E: Deep framework call chains with the same root pattern across many leaf methods

Look at the full stack signatures, not just the leaf. If you see the same multi-frame prefix (e.g., DispatcherServlet → Interceptor → Controller → Service → Repository) with different leaves, the framework dispatch itself is a non-trivial, if normal, cost. Worth quantifying, rarely worth fighting.

Thread Distribution

Also check which threads accumulate samples:

# Group samples by thread name
jfr print --events jdk.ExecutionSample recording.jfr | \
  grep "sampledThread" | sort | uniq -c | sort -rn

main thread dominates → Startup analysis: the main thread is doing the heavy lifting (object graph construction, class loading, initialization).
http-nio-* (or equivalent) threads dominate → Steady-state analysis: your request-handling threads are the bottleneck.
C2 CompilerThread* appears heavily → JIT compilation is consuming significant CPU (see Dimension 8).

When NOT to Optimize

Not every hot method deserves your attention. Before spending time on something you found in a CPU profile, ask:

Is it on a path that actually matters? A method that's hot exclusively during a one-time startup sequence matters a lot less than one that's hot on every request.
Does it consume a meaningful share of samples? A method with a handful of samples out of tens of thousands is noise, not signal (see the sampling-bias note above).
Is it actually user-visible? Shaving milliseconds off something nobody waits on doesn't move any metric that matters.
Is it unavoidable framework overhead? Plenty of methods show up as "hot" simply because the framework you chose does real, necessary work on every call. Fighting that is often lower-leverage than fixing something in your own code, or accepting it as the cost of the framework.

It's easy to spend an afternoon optimizing the third-hottest method in a profile only to discover it accounted for 2% of total time. Chase the few things that materially move the numbers you actually care about — not everything the profiler happens to surface.

4. Dimension 2: Memory Allocation Hotspots

Data source: jdk.ObjectAllocationSample events (available from JDK 16 onward). The JVM samples object allocations, recording the type, an estimated size (weight), and the allocation-site stack trace. This is a statistical profile of allocation throughput, not a heap dump — it doesn't tell you what's still alive, only what's being created.

What to Extract

jfr print --events jdk.ObjectAllocationSample --json recording.jfr

The JSON output includes objectClass.name and weight (an estimate of bytes allocated) for each sample, plus stackTrace.frames showing the allocation site.

Patterns and What They Mean

Pattern A: byte[] is a large share of allocated bytes

This is extremely common in JVM applications. Almost everything allocates byte[]: reading class files from JARs, deserializing JSON/XML, reading files, building response buffers, processing request bodies. The question is not really whether byte[] shows up near the top, but from where.

To find the allocation sites:

# Filter allocation stacks to only byte[] allocations
jfr print --events jdk.ObjectAllocationSample --json recording.jfr | \
  python3 -c "
import json, sys
from collections import Counter
data = json.load(sys.stdin)
stacks = Counter()
for e in data['recording']['events']:
    v = e['values']
    cls = v.get('objectClass', {}).get('name', '')
    if 'byte' in str(cls):
        frames = v.get('stackTrace', {}).get('frames', [])
        sig = ' -> '.join(f['method']['type']['name'] + '.' + f['method']['name'] for f in frames[:4])
        stacks[sig] += v.get('weight', 0)
for sig, w in stacks.most_common(20):
    print(f'{w:>12,d}  {sig}')
"

Typical culprits and their fixes:

Allocation site	Root cause	Fix
`Resource.getBytes` → `ClassLoader.defineClass`	Reading class bytes from JARs	CDS (pre-loaded classes)
`StreamDecoder.readBytes` → `SocketChannel.read`	Network I/O buffers	Defer or cache HTTP calls
`ByteArrayOutputStream.write` → Jackson/JSON	Serialization	Streaming/incremental serialization where feasible
ASM class-reading internals → `ClassReader.accept`	Bytecode parsing	Build-time/AOT processing where your framework supports it (reduces runtime parsing)

Pattern B: Framework internals dominate — annotation metadata, reflective Field/Method wrappers, proxy-related objects

These are your framework's internal representation of your object graph, annotations, and reflective access points, produced because the framework is doing runtime annotation processing and reflection to wire things up.

Optimization: Where available, build-time/AOT processing (offered in some form by most major DI frameworks) pre-computes much of this metadata instead of building it at runtime. CDS complements this by archiving the resulting classes and reducing re-parsing on subsequent runs.

Pattern C: Domain objects (your entities/DTOs) dominate

Your own data objects are the allocation leaders. This is application-level churn — consider:

Object pooling for frequently created/discarded objects (only where profiling justifies it — pooling has its own costs)
Reducing unnecessary DTO copies
Using primitive fields over boxed types where it matters
Caching instead of re-creating

The GC Connection

A quick clarification before going further, because it's a common source of confusion: allocation is not the same thing as memory usage. Allocation rate measures how much memory you create over time, regardless of how long any of it survives. Heap usage measures how much is currently retained. You can allocate 100MB of short-lived objects, immediately discard 99MB of it, and end up with only 1MB actually sitting in the heap — the allocation rate was 100MB, but the retained footprint was 1MB. Both numbers matter, but they answer different questions: allocation rate tells you how hard the GC has to work; heap usage tells you how large your working set actually is.

That connects directly to GC pressure: the amount of work the garbage collector has to do because the application keeps creating new objects. High allocation rates generally translate to high GC pressure — more frequent young-generation collections — even when the application's overall heap usage stays modest, because it's the rate of churn that drives collection frequency, not the retained size.

Putting the two together: allocation rate is a primary driver of young-generation GC frequency, so the more you allocate, the more often minor collections run. Reducing total allocation generally reduces GC pause time and frequency, though the relationship isn't perfectly linear — look at allocation hotspots first; GC improvements often follow.

5. Dimensions 3 & 4: GC / Heap Timeline and Pause Times

Data sources:

jdk.GCHeapSummary — periodic snapshots of heap usage
jdk.GCPhasePause — stop-the-world pause events, with phase-level detail

Not every GC-related event is enabled under every JFR configuration — the default recording is intentionally minimal. If these events come back empty, confirm you recorded with the profile settings template (or explicitly enabled the events you need), not the default one.

What to Extract

# Heap growth over time
jfr print --events jdk.GCHeapSummary --json recording.jfr

# GC pauses with phase breakdown
jfr print --events jdk.GCPhasePause --json recording.jfr

Reading the Heap Timeline

Plot heapUsed over startTime. The shape tells a story:

Rapid ramp-up then flat → Normal startup. The heap grows as beans, caches, and connection pools initialize, then stabilizes at steady-state.
Sawtooth pattern → Healthy GC. The heap grows between collections, then drops.
Ever-increasing with no drops → Possible memory leak or heap under sustained pressure. The heap grows because objects are outliving what you'd expect.
High peak usage relative to -Xmx → You're close to an OutOfMemoryError. Either increase the heap or reduce allocation.

Reading GC Pause Statistics

Aggregate then break down by phase:

Pause count:      45
Total pause time: 1,230 ms
Avg pause:        27.3 ms
Max pause:        180 ms
Pause % of recording: 4.1%

Rough rules of thumb (these vary by GC algorithm and workload, so treat as starting points, not thresholds): total pause time well under 5% of the recording, with only young-generation pauses, is generally healthy for most workloads. What's more concerning:

Total pause time climbing well past 5–10% → GC is struggling. Check allocation hotspots first (Dimension 2); reducing allocation is usually the cheapest way to reduce GC time.
Individual pauses well above your latency budget (e.g., over 100ms for a service targeting sub-200ms p95 latency) → At least one long stop-the-world event is impacting user-facing latency.
Any full/old-generation GC pause appears (naming depends on the collector — G1's Pause Full, or full/major cycles under other collectors) → The old generation is under pressure. This is typically the most expensive kind of collection. Investigate:
- Long-lived objects that should be short-lived (caching too aggressively?)
- Objects prematurely promoted to old gen (young gen too small relative to allocation rate?)
- A genuine memory leak (unbounded cache, unclosed resources)

By-phase breakdown tells you which type of collection dominates:

Phase	Indicates
Young-generation pauses dominate	Heavy short-lived allocation churn (normal)
Full/old-gen pauses appear	Old-gen pressure (investigate)
Remark/reference-processing phases are large	Large heap + many references to scan

Optimization for young-gen dominance: Tune young generation sizing (e.g., -XX:NewRatio, or your collector's equivalent) so objects die young instead of being promoted, or reduce allocation (Dimension 2).

Optimization for old-gen/full GCs: Increase old generation headroom, tune promotion thresholds, or fix the underlying leak.

Note: the exact event and phase names above depend on which GC you're running (G1 is the default in modern JDKs; ZGC and Shenandoah expose different, mostly-concurrent phase events). Confirm the phase names in your own recording rather than assuming G1's naming.

6. Dimension 5: Class Loading

Data source: jdk.ClassLoadingStatistics — cumulative counters of loaded and unloaded classes.

What to Extract

jfr print --events jdk.ClassLoadingStatistics --json recording.jfr

The last event in the series gives the final tally:

Classes loaded (final):    18,423
Classes unloaded (final):      47

What's Typical

Class counts vary a lot by application, but as a rough sense of scale:

Application type	Illustrative class count
Small app with a web server + a handful of libraries	Low thousands to ~15,000
Typical app-server app with several framework integrations (web, DI, ORM, messaging, etc.)	Higher, often 15,000–25,000+
Large monolith with many modules and dependencies	Can exceed 25,000–30,000
Minimal, dependency-light app	A few thousand

Every class you load costs:

Startup time — parsing, verifying, and linking the bytecode
Metaspace memory — class metadata is stored off-heap in Metaspace (typically on the order of a few hundred bytes to a few KB per class, depending on the class)
JIT compilation — more classes means more code that could potentially be compiled

Treat any "X classes ≈ Y MB of Metaspace" estimate as a ballpark, not a precise conversion — actual metadata size per class varies with class complexity.

Patterns

High loaded count relative to app size → You may have more dependencies on the classpath than you need. Audit with:

# Count classes in each JAR
jar tf your-app.jar | grep '\.class$' | awk -F/ '{print $1}' | sort | uniq -c | sort -rn

Optimization: Trim unused dependencies. Convenience dependency bundles (framework "starters," fat client libraries, umbrella artifacts) often pull in far more transitive classes than you actually use. Depend on narrower artifacts where available, or exclude unused transitive dependencies explicitly. CDS also reduces the runtime cost of each class regardless of count.

Nonzero or growing unloaded count → In many applications a small number of unloaded classes is unremarkable. If the unloaded count keeps growing over the life of a long-running process, that can indicate a classloader leak — a classloader being created and discarded repeatedly, often from dynamic proxies, scripting engines, or redeployed contexts. Worth investigating if it trends upward over time rather than staying flat.

7. Dimension 6: Thread Creation

Data sources: jdk.ThreadStart and jdk.ThreadEnd events.

What to Extract

jfr print --events jdk.ThreadStart --json recording.jfr
jfr print --events jdk.ThreadEnd --json recording.jfr

Grouping Threads by Pool

Thread names typically follow conventions: http-nio-8080-exec-1, http-nio-8080-exec-2 are the same pool. Strip trailing numbers to group them:

Pool prefix (typical examples)	What it represents
`http-nio--exec`, `qtp` (Jetty), `undertow-*`	Web-server request-handling threads
`HikariPool-`, `c3p0-`, or your driver/pool's naming	Database connection pool threads
`scheduling-`, `quartz-`	Scheduled/cron task executor threads
`reactor-http-*`, Netty event-loop names	Reactive/async I/O event-loop threads
`C2 CompilerThread`	JIT compiler threads (normal)
`ForkJoinPool.commonPool-*`	Parallel stream / CompletableFuture workers

Exact naming depends on your web server, connection pool, and scheduler libraries — the table above shows common examples, but the grouping principle (strip trailing numbers, bucket by prefix) applies regardless of which ones you're running.

What's Normal vs. Concerning

A few dozen threads is normal for a typical server-side app (a web-server thread pool + a database connection pool + a handful of schedulers + GC/JIT threads).
Hundreds of threads → Check for thread leaks or an oversized pool configuration. Each platform thread carries stack-space and scheduling overhead. Look for executors that create threads but never shut down, or pools configured with an unnecessarily high maximumPoolSize. And the same caution applies in the other direction: if contention analysis (Dimension 7) points you toward increasing a pool size, verify the fix with a before/after measurement rather than just cranking the number up — an oversized pool can itself increase contention and context-switching overhead, trading one bottleneck for another.
One-off threads (names that don't group into pools) → Each one has creation overhead. Consider a shared executor if they're frequent.

A note on virtual threads (JDK 21+): everything above assumes platform threads — a platform thread maps one-to-one to an OS thread, which is why each one is relatively expensive to create and hold. A virtual thread is different: it's a lightweight, JVM-managed thread that gets multiplexed onto a much smaller pool of platform threads (called carrier threads), so the JVM can support enormous numbers of them cheaply.

If your application uses virtual threads, raw thread counts stop being a reliable signal on their own — seeing thousands of virtual threads is normal and by design, not a leak. The concerning pattern shifts from "how many threads exist" to pinning (a virtual thread blocking its carrier thread instead of yielding it, often due to a synchronized block or certain native calls) and carrier-thread starvation (too few carrier threads available for the work being scheduled onto them). Those show up differently in a JFR recording — via jdk.VirtualThreadPinned events and general scheduling delay — rather than through simple thread-count totals.

8. Dimension 7: Lock Contention

Data sources:

jdk.JavaMonitorEnter — recorded when a thread blocks waiting to enter a synchronized block/method (intrinsic lock contention)
jdk.ThreadPark — waits on java.util.concurrent primitives (ReentrantLock, CountDownLatch, Semaphore, etc.)

By default, JFR only records monitor-contention events above a threshold (commonly 20ms) — shorter contention won't show up unless you lower that threshold when starting the recording, at the cost of more overhead.

What to Extract

jfr print --events jdk.JavaMonitorEnter --json recording.jfr
jfr print --events jdk.ThreadPark --json recording.jfr

For each event, extract the contended/parked class name and the wait duration.

Worth keeping in mind: a jdk.ThreadPark event by itself is not automatically a problem. Parking is the normal, intended mechanism behind most java.util.concurrent waiting — a thread sitting idle in an executor waiting for work, or a scheduled task waiting for its next run, will generate park events constantly without indicating anything wrong. What makes park time worth investigating is the combination of where it's happening (the stack trace) and how much of it there is relative to the work being done — a thread parking while genuinely idle is fine; a thread parking while it's supposed to be actively serving requests is the pattern to chase.

Patterns

Monitor enter on java.lang.Class objects → Static synchronized methods or synchronized(MyClass.class) blocks. Class-level locks are particularly bad because they serialize all threads contending on that class, not just per-instance callers.

Monitor enter on Logger / logging internals → Synchronized logging. Consider an async logger (e.g., Log4j2's async loggers) if this shows up as significant contention.

Park on a connection-pool's internal lock (HikariCP, c3p0, or others) → Connection pool contention. If threads are parking waiting for a database connection, consider increasing the pool's max size (only after checking whether the DB and queries can actually support more concurrent connections) or investigate slow queries holding connections longer than necessary.

Park on CountDownLatch / CyclicBarrier with high counts → Thread coordination that's spending more time waiting than working. Check if the parallelism is appropriate for your hardware.

How to Read the Numbers

Monitor enter events:   847    total wait:   342.1 ms
Thread park events:   2,103    total park:  1,892.6 ms

Park time notably higher than monitor-enter time → Contention is more concentrated in java.util.concurrent structures than synchronized blocks — common in modern applications and frameworks that lean on the concurrency utilities rather than intrinsic locks.
Total wait a meaningful fraction of recording time (rough guide: worth a look above roughly 5%) → Contention is meaningful. Below 1–2%, it's usually not worth chasing — the wins will be marginal relative to the effort.

9. Dimension 8: JIT Compilation

Data source: jdk.Compilation events. One event per compiled method, recording the method signature, compile level, and compilation duration.

What to Extract

jfr print --events jdk.Compilation --json recording.jfr

Understanding Compile Levels

Modern JVMs don't compile everything the same way. Instead, tiered compilation runs code through progressively more sophisticated compilers as it proves itself "hot" enough to be worth the investment:

Interpreter  →  C1  →  C2
(slow to run,   (fast to compile,   (expensive to compile,
 no compile      moderately         most optimized,
 delay)          optimized)         best steady-state speed)

New code starts in the interpreter, which runs slowly but has zero compilation delay. Code that gets called often is compiled by C1, a quick compiler that produces reasonably fast code without spending much time compiling. Code that's still hot after that gets recompiled by C2, a much more thorough optimizing compiler that takes longer to run but produces the fastest possible code, using the profiling data gathered along the way. This staged approach is why a JVM's startup performance and its long-running, steady-state performance are genuinely different regimes — a short-lived process may never get past C1 for most of its code, while a long-running server eventually gets its hot paths onto C2.

Broken down into JFR's numeric compile levels:

Level	Name	Description
0	Interpreter	No compilation — interpreted bytecode
1	C1, no profiling	Simple C1 compile, fastest to produce
2	C1, limited profiling	C1 with basic invocation/loop counters
3	C1, full profiling	C1 with full profiling (gathers data used to decide on C2)
4	C2	Full optimizing compiler — most expensive to produce, highest steady-state performance

The Startup Compilation Trade-off

During startup, hot methods are typically compiled first at cheaper C1 levels, then re-compiled at level 4 once the JIT has gathered enough profiling data to justify it. This tiered approach favors faster ramp-up at the cost of some methods being compiled more than once.

Compilations:      2,847
Total compile time: 3,452 ms
Compile time % of recording: 11.5%

Few or no level-4 compilations → Code isn't reaching full optimization. Peak throughput may suffer if the process runs long enough to matter.
Heavy, sustained level-4 activity → The JIT is working hard. For startup-sensitive, short-lived, or CLI-style applications where peak throughput matters less than time-to-first-response, consider C1-only mode:

java -XX:TieredStopAtLevel=1 -jar my-app.jar

This disables C2 entirely. You give up C2's deeper optimizations (aggressive inlining, loop unrolling, escape analysis, etc.) in exchange for saving all C2 compilation CPU. Worth it for batch jobs, CLI tools, or anything where the process exits before C2 would have paid for itself — not a good default for a long-running, throughput-sensitive service.

Top compiled methods by time show which code paths trigger the most expensive compilations. Application methods appearing here (as opposed to framework code) are hot paths the JIT considers worth optimizing — probably worth a look regardless of your JIT tuning.

10. Dimension 9: Socket / File I/O

Data sources:

jdk.SocketRead / jdk.SocketWrite — network I/O with host, bytes, and duration
jdk.FileRead / jdk.FileWrite — file I/O with path, bytes, and duration

What to Extract

jfr print --events jdk.SocketRead,jdk.SocketWrite --json recording.jfr
jfr print --events jdk.FileRead,jdk.FileWrite --json recording.jfr

Reading I/O Patterns

Socket I/O during startup — every network call during ApplicationRunner / @PostConstruct delays readiness. Look for:

Database connection establishment (expected, but should happen once)
HTTP calls to external services (configuration fetching, health checks, service discovery)
Redis/Memcached connection setup (expected)
Unexpected HTTP calls (e.g., XML schema validation fetching remote DTDs)

Optimization: Defer non-critical network calls to after the application is ready (ApplicationReadyEvent). Cache responses that don't change between restarts. Use connection pooling to amortize handshake cost.

File I/O duration — the duration field on FileRead/FileWrite events captures the time the call took, including any blocking wait, not just CPU-side processing. High wait time on:

Path pattern	Suggests
`*.jar`	Classpath scanning — CDS can help
`*.class`	Class loading from exploded directories — CDS or packaging as a jar can help
`application.yml` / `.properties`	Config file loading — normal, but check for excessive includes
`/etc/`, `/usr/`	System-level file access — unusual, worth investigating
Database files	If using an embedded DB (e.g., H2), the DB files are being read directly

11. Dimension 10: CPU Load Timeline

Data source: jdk.CPULoad — periodic snapshots of JVM user CPU, JVM system CPU, and total machine CPU.

What to Extract

jfr print --events jdk.CPULoad --json recording.jfr

Interpreting the Three Numbers

Metric	Meaning
JVM user%	CPU spent in JVM user-mode code (your app + framework + JIT)
JVM system%	CPU spent in kernel on behalf of the JVM (I/O syscalls, thread scheduling, some GC activity)
Machine total%	Total CPU utilization across all processes on the host

Patterns:

JVM user% + system% ≈ machine total% → The JVM is the dominant CPU consumer on the box. You're compute-bound — optimize CPU hotspots (Dimension 1).
High system% relative to user% → The JVM is spending an unusual amount of time in kernel space. Points toward heavy I/O (Dimension 9) or heavy thread context switching (Dimension 6).
Machine total% near 100% but JVM% is comparatively low → Something else on the host is consuming CPU. Your JVM isn't the bottleneck — look at co-located processes.
Low JVM% and low machine% → The JVM is waiting on something external (I/O, locks, or genuinely idle). Check thread idle time (Dimension 11).

12. Dimension 11: Thread Idle / Sleep Time

Data sources: jdk.ThreadSleep (explicit Thread.sleep() calls) and jdk.JavaMonitorWait (Object.wait()), alongside jdk.ThreadPark already covered in Dimension 7 for java.util.concurrent waits. Together these three event types cover most of the ways a thread can be voluntarily idle rather than blocked on I/O or a contended lock.

A note on terminology: some third-party profilers (notably async-profiler's wall-clock mode) offer a more general "wall clock" sampling approach that periodically samples every thread's state regardless of whether it's running, sleeping, or blocked — useful for a single unified idle-time view. Standard JFR doesn't have one combined event for this; you assemble the picture from the events above.

What to Extract

jfr print --events jdk.ThreadSleep,jdk.JavaMonitorWait,jdk.ThreadPark --json recording.jfr

Each event's duration field tells you how long the thread was idle, and its stack trace shows where the thread entered that state.

Patterns

main thread has high idle/sleep time during startup → The main thread is waiting on something. Check what the top frame is:

Socket.connect or a related network call → Waiting for a network connection
FileInputStream.read → Waiting for file I/O
CountDownLatch.await → Waiting for another thread to complete initialization
Thread.sleep → Explicit sleep (sometimes intentional — e.g., a documented retry backoff — sometimes worth questioning if it's on the startup critical path)

Thread-pool threads dominate idle time → Those threads are spending most of their time waiting for work. Normal during idle periods for request-handling pools; if you're profiling a busy period and pool threads are still mostly idle, the bottleneck is upstream — not enough requests arriving, or work isn't being distributed to them.

Longest individual idle events — look at the top 10–15 by duration. These are your "long poles" — single events that dominate the timeline. Each is a candidate for targeted optimization:

Duration  Thread    Top Frame
 8,234 ms  main      java.net.Socket.connect
 4,102 ms  main      java.io.FileInputStream.read
 1,892 ms  main      java.util.concurrent.CountDownLatch.await

In an example like this, the socket connect and file read alone could account for the majority of a short startup window — a strong signal that those two call sites are worth optimizing first.

13. Dimension 12: Before/After Comparison

The most rigorous way to validate an optimization is to compare two JFR recordings — one before the change, one after — captured under the same workload and conditions.

Methodology

Record Before: Capture a JFR recording of the baseline.
Make exactly one change: -XX:TieredStopAtLevel=1, or CDS, or AOT, or dependency trimming.
Record After: Capture a second recording with the same JFR settings, same duration, same workload.
Compare across all dimensions: Don't cherry-pick. Check every section — an optimization that improves CPU but worsens allocation may be a net negative depending on your priorities.

What to Compare (and What's Noise)

High-signal metrics (deltas worth taking seriously, roughly >10%):

Metric	Why it matters
Total allocation (bytes)	Directly drives GC pressure
GC pause count + total time	Directly impacts responsiveness
Classes loaded	Impacts startup time + Metaspace
JIT compile time	Impacts startup CPU
Thread idle/sleep time	Impacts latency / readiness

Medium-signal metrics (look for larger deltas, roughly >30%, before drawing conclusions):

Metric	Why it matters
CPU sample count	Rough proxy for total work done
`byte[]` allocation specifically	Primary GC driver for many apps
Lock contention wait time	Impacts throughput under concurrency
File I/O bytes + wait time	Impacts startup latency
Socket I/O bytes + wait time	Impacts network-dependent readiness

Low-signal metrics (small deltas here are often sampling noise — pay attention mainly when something appears or disappears entirely):

Small allocation-type deltas (on the order of a few MB or less, depending on total recording size)
Individual hot methods with only a handful of samples in either recording
Thread count changes of one or two

The Eliminated / New Pattern

In the comparison, flag items that were significant in the Before recording but are essentially absent in After, and vice versa. These are often the clearest wins — not "we reduced this by 15%," but "this cost is gone."

Type                         Before          After          Delta
byte[]                       48,123,456           0    -48,123,456 (-100%) ◀◀ ELIMINATED
TypeMappedAnnotations        12,456,789     892,123    -11,564,666 (-92.8%)

An eliminated byte[] allocation like that is consistent with what CDS does for class-loading-related allocations — the class bytes come from the shared archive instead of being read and inflated at runtime. A large drop in annotation-metadata allocation is consistent with AOT pre-computing that metadata instead of building it at runtime. (As always, correlation from a before/after diff is a strong hint, not proof — confirm against the change you actually made.)

14. Putting It All Together: A Systematic Analysis Protocol

Here's a workflow for approaching a .jfr file when the question is "why is this slow":

Step 1: Orient

Read the recording metadata — JVM version, JVM arguments, recording duration. A very short recording doesn't have enough samples to be reliable. A recording with a small -Xmx explains why GC is thrashing. Know the context first.

Step 2: Profile CPU

Extract ExecutionSample events (text mode for stack traces). Identify the top leaf methods and top stack signatures. If ClassLoader.defineClass dominates → CDS. If annotation scanning dominates → indexer/AOT. If application code dominates → profile deeper into those methods.

Step 3: Profile Allocation

Extract ObjectAllocationSample events (JSON mode for weights). Identify the top allocation types by bytes. For byte[], drill into allocation-site stacks. Map each major allocation site to a fix (CDS → class bytes, AOT → annotation metadata, caching → repeated object creation).

Step 4: Check GC Health

Extract GCHeapSummary + GCPhasePause. Plot the heap curve; look at pause statistics. If pause time is a large share of the recording, return to Step 3 — the fix is usually reducing allocation. If old-gen/full GCs appear, investigate separately.

Step 5: Audit the Rest

Work through class loading, threads, locks, JIT, I/O, and idle time. Each may reveal a secondary bottleneck. The longest individual idle events often point to "long pole" optimizations — single changes that remove seconds of waiting.

Step 6: Compare (if you have Before/After)

Run every section side-by-side. Focus on eliminated items and large-magnitude deltas. Verify that improvements in one dimension didn't regress another.

15. A Worked Example

To make the protocol concrete, here's an illustrative (simplified, representative-of-the-shape-not-exact-numbers) walkthrough of applying it to a slow-starting application.

Baseline: Startup takes 18 seconds.

Step 2 — CPU: ExecutionSample shows ClassLoader.defineClass1 accounting for roughly 45% of samples during the startup window — Pattern A from Dimension 1.

Step 3 — Allocation: ObjectAllocationSample shows byte[] at roughly 38% of allocated bytes, with the allocation-site stacks tracing back through class-file reading — consistent with the CPU finding.

Step 4 — GC: 17 young-generation collections over the recording, unremarkable pause times, no full GCs. GC isn't the bottleneck here — the allocation churn is a symptom of class loading, not a separate problem.

Diagnosis: Both the CPU profile and the allocation profile point at the same root cause — class loading and parsing dominates startup.

Change made: Enable CDS (-XX:ArchiveClassesAtExit / -XX:SharedArchiveFile), one change, nothing else.

After: Startup takes 11 seconds.

Metric                Before      After      Delta
Startup time           18.0 s     11.0 s     -39%
CPU: ClassLoader          45%         14%     -31 pts
Allocation: byte[]        38%          9%     -29 pts
Minor GCs                  17          8      -9

Step 6 — Verify: The CPU share, the allocation share, and the GC count all moved together in the direction the diagnosis predicted, and the change made (CDS) is a plausible mechanism for exactly that combination of effects — class-loading CPU down, class-byte allocation down, and fewer minor GCs because there's less churn to collect. That consistency across independent dimensions is what turns "we made a change and it got faster" into a reasonably confident causal story, rather than a coincidence.

Notice what this example does not do: it doesn't stop at "startup got faster," it checks that the mechanism (less class-loading work) is visible in more than one independent dimension of the data. A change that improves one number while an unrelated number gets worse is worth a second look before declaring victory.

16. Common JFR Mistakes

A few patterns that undermine an otherwise sound analysis:

Recording too long. A five-minute recording spanning startup, steady-state, and idle time averages all three together — none of the resulting numbers describe any single phase well. Record the specific window you care about.
Comparing different workloads. A before/after comparison is only meaningful if both recordings saw the same requests, the same data, and the same duration. Comparing a quiet-period recording to a load-test recording tells you about the workload difference, not your change.
Optimizing methods with only a handful of samples. Low sample counts are noise, not signal (see the sampling-bias note in Dimension 1) — chasing them wastes effort that could go toward something statistically meaningful.
Looking only at CPU. A CPU-only view misses allocation-driven GC pressure, I/O waits, and lock contention — all of which can dominate wall-clock time without showing up as CPU samples at all.
Ignoring allocation. Allocation rate drives GC pressure well before heap usage looks alarming; waiting for a heap problem to show up before checking allocation means you're diagnosing late.
Ignoring idle time. A method that's cheap on CPU can still be the reason startup is slow, if it's blocking on I/O or a latch. CPU profiling alone won't surface that — Dimension 11 will.
Comparing across different JVM versions or GC algorithms. Event names, phase names, and default behaviors can differ between JDK versions and collectors. A before/after comparison should hold the JVM version and GC algorithm constant unless that's specifically the change being tested.

17. Conclusion

A JFR recording is more than a performance trace — it's a map of how your JVM actually spends its time and resources, as opposed to how you assume it does. By systematically working through CPU, allocation, garbage collection, class loading, threads, synchronization, JIT compilation, and I/O, you replace guesswork with evidence.

The point isn't to chase every hotspot the profiler surfaces — plenty of what shows up is normal, unavoidable framework overhead or startup-only cost that will never matter in production. The point is to find the handful of bottlenecks that materially affect startup time, latency, or throughput; make one change at a time; and verify the result with another recording, checking that the numbers moved the way your diagnosis predicted before calling it done.

Building a Dual-Mode Monolith/Microservices System with Spring Boot - One Codebase, Two Topologies

2026-08-02T19:58:02.506+01:00

How to build a single codebase that deploys as either a monolith or independent microservices — and why you might want to.

Monolith-to-microservices rewrites are expensive, and most teams don't actually know which topology they need until they're already committed to one. The usual fix is to guess, build, and rewrite later when the guess turns out wrong.

There's a third option: ship both from day one, from the same codebase, the same tests, and the same CI pipeline.

That's what the dual-architecture pattern does. Three Spring Boot services — Order, Inventory, and Shipping — live in one repo, share one set of interfaces, and deploy identically whether they're running as a single JAR or as independently scaled services. Switching topology is a single property: deployment.mode.

In this post, I'll walk through how it works, how to set it up, and how it compares to Spring Modulith — along with the trade-offs that matter once you're past the prototype stage.

The Problem It Solves

Scenario	Monolith	Microservices
Early-stage startup	✅ Fast to build, one deployable	❌ Operational overhead kills velocity
Enterprise with dedicated ops	❌ Can't scale teams independently	✅ Teams own their services end-to-end
On-premise customer	✅ Single JAR, simple install	❌ Requiring Kubernetes is a dealbreaker
Cloud-native customer	❌ Wastes resources scaling monolithically	✅ Scales inventory independently of ordering
Vendor selling to both	Needs to support both at once, without maintaining two codebases

If you're building software that different customers deploy differently — or you're a growing team that wants to defer the monolith-vs-microservices decision — you need a codebase that supports both topologies without forking. That's what this architecture delivers.

How It Works: The Three Pillars

Pillar 1: A Shared Contract (the Client Interface)

Every cross-service interaction starts with a plain Java interface in a shared common-api module:

// common-api/src/main/java/com/monoservice/common/api/InventoryClient.java
public interface InventoryClient {
    boolean checkStock(String sku, int quantity);
    ReservationResult reserveStock(String sku, int quantity);
    void releaseStock(String sku, int quantity);
    int getAvailableQuantity(String sku);
}

Domain services never know whether the implementation lives in-process or across the network — they just inject the interface:

// order-service/.../OrderDomainService.java
@Service
@RequiredArgsConstructor
public class OrderDomainService {
    private final InventoryClient inventoryClient;  // ← just the interface
    private final OrderEventGateway eventGateway;

    @Transactional
    public OrderResult placeOrder(PlaceOrderRequest request) {
        if (!inventoryClient.checkStock(request.sku(), request.quantity())) {
            throw new InsufficientStockException(request.sku());
        }
        inventoryClient.reserveStock(request.sku(), request.quantity());
        // ... persist order, publish event
    }
}

No if (mode == MONOLITH) branches, no proxy magic — just polymorphism, wired by the container.

Pillar 2: Two Implementations, Conditionally Wired

For each Client interface, you write two implementations, and Spring picks the right one based on a property:

// Monolith mode — direct method call, same JVM, same transaction
@Component
@ConditionalOnProperty(name = "deployment.mode", havingValue = "monolith")
public class InventoryClientLocal implements InventoryClient {

    private final InventoryDomainService domainService;

    @Override
    public boolean checkStock(String sku, int quantity) {
        return domainService.checkStock(sku, quantity);
    }

    @Override
    public ReservationResult reserveStock(String sku, int quantity) {
        return domainService.reserveStock(sku, quantity);
    }
    // ...
}

// Microservices mode — HTTP call via Feign
@FeignClient(name = "inventory-service",
             url = "${services.inventory.url:http://inventory-service:8080}")
@ConditionalOnProperty(name = "deployment.mode", havingValue = "microservices")
public interface InventoryClientRemote extends InventoryClient {

    @Override
    @GetMapping("/api/inventory/check")
    boolean checkStock(@RequestParam("sku") String sku, @RequestParam("qty") int quantity);

    @Override
    @PostMapping("/api/inventory/reserve")
    ReservationResult reserveStock(@RequestParam("sku") String sku,
                                    @RequestParam("qty") int quantity);
    // ...
}

deployment.mode=monolith activates the local adapter; deployment.mode=microservices activates the Feign client. @ConditionalOnProperty handles the rest — no custom condition classes, no proxy factories, no bytecode generation. It's plain Spring you already know.

Pillar 3: Dual-Path Event Routing

Cross-service asynchronous communication follows the same pattern. Each service defines an event gateway that publishes identically in both modes:

@Component
public class OrderEventGateway {
    private final ApplicationEventPublisher eventPublisher;
    private final ObjectProvider<KafkaTemplate<String, Object>> kafka;

    public void publish(Object event) {
        eventPublisher.publishEvent(event);  // always — for in-process listeners

        kafka.ifAvailable(template ->        // only when Kafka is on the classpath
            template.send("order.events." + event.getClass().getSimpleName(), event)
        );
    }
}

On the receiving side, two listeners — only one active per mode — handle the same event, both implementing a shared OrderPlacedHandler interface to keep the contract explicit and testable:

// Monolith: synchronous, within the publishing transaction's lifecycle
@Component
@ConditionalOnProperty(name = "deployment.mode", havingValue = "monolith")
public class InventoryOrderPlacedListener implements OrderPlacedHandler {

    @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
    public void handle(OrderPlacedEvent event) {
        domainService.reserveStock(event.sku(), event.quantity());
    }
}

// Microservices: async, from Kafka
@Component
@ConditionalOnProperty(name = "deployment.mode", havingValue = "microservices")
public class InventoryOrderPlacedKafkaListener implements OrderPlacedHandler {

    @KafkaListener(topics = "order.events.OrderPlacedEvent",
                   groupId = "inventory-service")
    public void handle(OrderPlacedEvent event) {
        domainService.reserveStock(event.sku(), event.quantity());
    }
}

The Project Structure

Putting it together, the repo looks like this:

mono-service/
├── common-api/              # Shared interfaces, DTOs, events, Feign clients
├── order-service/           # Own @SpringBootApplication, port 8081
├── inventory-service/       # Own @SpringBootApplication, port 8082
├── shipping-service/        # Own @SpringBootApplication, port 8083
├── monolith-app/            # Aggregator — depends on all three, port 8080
├── docker/                  # Dockerfile + docker-compose (both modes)
├── k8s/                     # Kubernetes manifests — monolith/ and microservices/
└── e2e/                     # Mode-agnostic test suite (29 assertions)

Each service is a standalone Spring Boot application, with its own main method, its own configuration, and its own database migrations. monolith-app is just a fourth application that bundles all three as Gradle dependencies, scans the unified package namespace, and excludes the Kafka- and Feign-related autoconfiguration it doesn't need.

The Mode Switch in Configuration

Monolith (monolith-app/src/main/resources/application-monolith.yml):

deployment:
  mode: monolith

spring:
  autoconfigure:
    exclude:
      - org.springframework.boot.autoconfigure.kafka.KafkaAutoConfiguration
      - org.springframework.cloud.openfeign.FeignAutoConfiguration
  datasource:
    url: jdbc:postgresql://localhost:5432/shop
  liquibase:
    enabled: true          # One DB, three schemas
  flyway:
    enabled: false

Microservices (order-service/src/main/resources/application.yml):

deployment:
  mode: microservices

spring:
  kafka:
    bootstrap-servers: localhost:9092
  flyway:
    enabled: true           # Per-service database

services:
  inventory:
    url: http://inventory-service:8080
  shipping:
    url: http://shipping-service:8080

Database Strategy

This is where the pattern gets interesting — the dual architecture handles database evolution differently in each mode:

Aspect	Monolith	Microservices
Databases	One PostgreSQL (`shop`)	Three PostgreSQL (`orders`, `inventory`, `shipping`)
Schemas	Three schemas in one DB	One schema per DB
Migrations	Liquibase (runs all SQL in order)	Flyway (per-service, independent)
SQL files	Same files, different tool	Same files, different tool
Cross-schema FKs	None — application-level integrity	None — application-level integrity

The SQL migration files are authored once and consumed by both tools. Liquibase references them via a master changelog; Flyway picks them up natively from each service's classpath. This avoids the single worst failure mode of dual architectures: diverging schema definitions.

No cross-schema foreign keys means no mode-specific data integrity rules. If you wouldn't trust it across the network, don't trust it across schemas.

How Spring Modulith Compares

If you're thinking "this sounds like Spring Modulith," you're right — and the differences are instructive.

Spring Modulith verifies and enforces module boundaries within a modular monolith. It gives you:

Module structure verification — ArchUnit-style tests that catch illegal dependencies between modules at build time.
Event publication — an ApplicationModuleListener annotation that formalizes in-process event handling.
Documentation — auto-generated diagrams of your module topology.
Testing support — ModuleTest for testing modules in isolation.

What Modulith doesn't do is provide a config-driven switch between local method calls and remote HTTP calls — it assumes you're a monolith. If you later split out a module into its own service, you're rewriting the integration points: replacing direct calls with HTTP, adding circuit breakers, dealing with distributed transactions.

The dual-architecture pattern instead writes the integration point once (the Client interface), implements both paths from the start, and lets a property choose. The cost is upfront: two implementations per interface, conditional beans, dual-tool database migrations. The payoff is that you never rewrite an integration.

Concern	Spring Modulith	Dual Architecture
Module boundary enforcement	✅ Compile-time verification	⚠️ By convention only
Deploy as monolith	✅ Natural	✅ Natural
Deploy as microservices	❌ Requires rewrite of integrations	✅ Built-in, same artifact
Event system	`@ApplicationModuleListener`	Spring Events + Kafka (conditional)
Database strategy	Single DB recommended	Single DB or separate DBs
Learning curve	Low (annotations you already know)	Medium (more moving parts)
Framework dependency	Heavy (spring-modulith-starter)	None (plain Spring Boot + Feign)
Good for	Teams committed to monolith, wanting discipline	Teams that need both topologies from day one

Neither is "better" — they solve different problems. If you're sure you'll be a monolith forever, Modulith's compile-time verification and lighter footprint win. If you might split, or you sell to customers who need different topologies, the dual architecture prevents a rewrite.

What Makes It Work (and What Doesn't)

What works well

@ConditionalOnProperty is the right abstraction level. You don't need a custom framework — a single property, standard Spring annotations, and a discipline of always pairing local and remote implementations is enough.
Controllers implementing the Client interfaces catches drift at compile time. If InventoryController implements InventoryClient, the compiler guarantees the REST endpoint signatures match the Feign client's expectations. No more "the URL changed but the client wasn't updated" bugs.
The same E2E tests run in both modes. The test suite (run-tests.sh) is parameterized only by base URLs and asserts the same 29 behaviors against monolith and microservices deployments. If the tests pass in both modes, you haven't introduced a topology-dependent bug.
The aggregator app is a separate module, not a profile. monolith-app is its own Gradle module that depends on all three services — it doesn't reconfigure them internally. This means each service can still be built, tested, and deployed independently; the monolith is a consumer of services, not a special mode of each one.

What's tricky

The Feign clients live in common-api, which pulls spring-cloud-starter-openfeign into every module — including ones that never make an HTTP call in monolith mode. You end up excluding it manually in the aggregator (as shown above). A cleaner alternative is to move the Feign interfaces into the consumer module (e.g., InventoryClientRemote inside order-service), keeping common-api free of network dependencies entirely.
Event semantics differ silently between modes. In monolith mode, events are synchronous and transactional (@TransactionalEventListener(AFTER_COMMIT)). In microservices mode, events are async and at-least-once (Kafka). Code that works in one mode can fail subtly in the other — duplicate processing, missing transactional rollback, reordering. The only real defense is idempotency keys on every event, plus running the full test suite in both modes on every change.
There's no compile-time module boundary check. Unlike Modulith, nothing stops order-service from importing inventory-service's entity classes directly and bypassing the InventoryClient abstraction entirely. You need either discipline or an ArchUnit test that bans cross-module imports.

# Clone and build
./gradlew build -x test

# Run as monolith — all three services in one process
SPRING_PROFILES_ACTIVE=monolith ./gradlew :monolith-app:bootRun

# Or run as microservices — three independent processes
./gradlew :order-service:bootRun &
./gradlew :inventory-service:bootRun &
./gradlew :shipping-service:bootRun &

# Same E2E tests, both modes
MODE=monolith BASE_URL=http://localhost:8080 ./e2e/run-tests.sh
MODE=microservices \
  ORDER_URL=http://localhost:8081 \
  INVENTORY_URL=http://localhost:8082 \
  SHIPPING_URL=http://localhost:8083 \
  ./e2e/run-tests.sh

Key Takeaways

One codebase, two deployment topologies is a real, practical architecture — not an academic exercise.
Three pillars make it work: shared Client interfaces, conditionally-wired local/remote implementations, and dual-path event routing.
Spring Modulith and this pattern solve different problems. Modulith enforces monolith discipline; the dual architecture enables topology switching.
@ConditionalOnProperty is simpler and more transparent than a custom framework for this.
The biggest risk is mode-specific behavioral divergence — mitigate it with idempotency, identical E2E tests in both modes, and compile-time contract verification wherever you can get it.

For teams selling the same product into both monolith and microservices customers, this pattern eliminates the most expensive decision in backend architecture: the one you have to make before you know the answer.

Spring Boot - update response of every API using ResponseBodyAdvice

2025-03-11T01:05:00.001+00:00

Not sure why we need it but I've seen several codebase where developers were wrapping the response body in some structure like below - where the actual content is put under an element eg: body and the root object has several other values.

{
  "body": { //the actual body
    "greeting": "Hello World!"
  },

  //additional elements
  "timestamp": 1741653577468,
  "traceId": "67cf8649f3c848a71d8171473d3b4955",
  "spanId": "1d8171473d3b4955",
  "durationMs": 0,
  "status": 200
}

The corresponding controller method would look something like below where they would explicitly create the ResponseObject and map other parameters in every single endpoint definition:

@GetMapping("/object-bad-way/hi")
public ResponseObject<Hi> oldWayHi() {
    log.info("Got request -  object - old way - don't do this, use ResponseBodyAdvice");
    var resp = new ResponseObject<Hi>();
    var span = tracer.currentSpan();
    if (span != null) {
        resp.setTraceId(span.context().traceId());
        resp.setSpanId(span.context().spanId());
    }

    resp.setTimestamp(System.currentTimeMillis());
    try {
        resp.setBody(myService.getHi()); //service call
        resp.setStatus(HttpStatus.OK.value());
    } catch (Exception e) {
        resp.setStatus(HttpStatus.INTERNAL_SERVER_ERROR.value());
    }

    return resp;
}

The ResponseObject:

@Getter
@Setter
class ResponseObject<T> {
    T body;
    long timestamp;

    String traceId;
    String spanId;

    long durationMs;
    int status;
}

But wait, there's a better way to do this if you really want this. The idea is to use Spring's @ControllerAdvice that implements ResponseBodyAdvice to map the additional params so that you don't need to create the new ResponseObject instance on all endpoints.

After the change, your controller method would look simple as below: wouldn't that be nice?

@GetMapping("/better-way/hi")
public Hi objectHi() {
    log.info("Got request -  object");
    return service.getHi();
}

ResponseBodyAdvice

From the docs:

ResponseBodyAdvice allows customizing the response after the execution of an @ResponseBody or a ResponseEntity controller method but before the body is written with an HttpMessageConverter.
Implementations may be registered directly with RequestMappingHandlerAdapter and ExceptionHandlerExceptionResolver or more likely annotated with @ControllerAdvice in which case they will be auto-detected by both.

A simple (empty) usage would look like this. On the supports method, we can decide if the response body needs to be modified. The beforeBodyWrite is where we can modify the request body or create new.

@ControllerAdvice
class ObjectResponseAdvice implements ResponseBodyAdvice<Object> {

    //Whether this component supports the given controller method return type and the selected HttpMessageConverter type.
    public boolean supports(MethodParameter returnType, Class<? extends HttpMessageConverter<?>> converterType) {
        return true;
    }

    //Invoked after an HttpMessageConverter is selected and just before its write method is invoked.
    public Object beforeBodyWrite(Object body, MethodParameter returnType,
                                  MediaType selectedContentType, Class<? extends HttpMessageConverter<?>> selectedConverterType, ServerHttpRequest request, ServerHttpResponse response) {
        //modify body
        return body;
    }
}

A simple implementation of beforeBodyWrite that would work with both String response type and any other response type. Here we are handling the String response specially by checking if the original body(response body) is String. Otherwise, we are creating a ObjectNode and mapping timestamp and body elements under it.

supports() method: 
    return true;


beforeBodyWrit() method:

  ObjectNode root = objectMapper.createObjectNode();
  root.put("timestamp", System.currentTimeMillis());

  if (body instanceof String) {
    root.set("body", objectMapper.convertValue(body, JsonNode.class));
    return objectMapper.writeValueAsString(root);
  } else {
    root.put("body", String.valueOf(body));
    return root;
  }

Handle more stuff and map more stuff:

Here we are mapping the traceId/spanId from Micrometer Tracing , mapping 'status' from ServletServerHttpResponse. Also for backward compatibility with existing RestController methods that already return ResponseObject (with all elements we want on the response), we are skipping the additional mapping and simply returning body.

if (response instanceof ServletServerHttpResponse resp
        //if body is already ResponseObject  - do not convert
        && !(body instanceof ResponseObject)) {

    ObjectNode root = objectMapper.createObjectNode();
    var span = tracer.currentSpan();
    if (span != null) {
        root.put("traceId", span.context().traceId());
        root.put("spanId", span.context().spanId());
    }
    root.put("status", resp.getServletResponse().getStatus());
    if (BeanUtils.isSimpleValueType(body.getClass())) {
        root.put("body", String.valueOf(body));
    } else {
        root.set("body", objectMapper.convertValue(body, JsonNode.class));
    }
    root.put("timestamp", System.currentTimeMillis());

    if (body instanceof String) {
        // String are handled special case with StringHttpMessageConverter
        // we need to return String from this method
        return objectMapper.writeValueAsString(root);
    } else {
        return root;
    }
}

Full code in action: Note that it supports, string type, int type, map, and any object response.

Test it out with following endpoints:

###
GET http://localhost:8080/string

###
GET http://localhost:8080/map

###
GET http://localhost:8080/object/hi

###
GET http://localhost:8080/object/hello

###
GET http://localhost:8080/object-bad-way/hi

###
GET http://localhost:8080/object-bad-way/hello

Full Code:

package responsebody;

import com.fasterxml.jackson.databind.*;
import com.fasterxml.jackson.databind.node.ObjectNode;
import io.micrometer.tracing.Tracer;
import lombok.*;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.BeanUtils;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.core.MethodParameter;
import org.springframework.http.*;
import org.springframework.http.converter.HttpMessageConverter;
import org.springframework.http.server.*;
import org.springframework.web.bind.annotation.*;
import org.springframework.web.servlet.mvc.method.annotation.ResponseBodyAdvice;

import java.net.*;
import java.util.Map;

@SpringBootApplication
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

@RestController
@Slf4j
@RequiredArgsConstructor
class GreetingController {

    final Tracer tracer;

    @GetMapping("/string")
    public String string() {
        log.info("Got request - string");
        return "Hello World!";
    }

    @GetMapping("/int")
    public int intVal() {
        log.info("Got request - int");
        return 1;
    }

    @GetMapping("/url")
    public URL url() throws MalformedURLException {
        log.info("Got request - url");
        return URI.create("https://localhost:8080/").toURL();
    }

    @GetMapping("/map")
    public Map<String, String> map() {
        log.info("Got request - map");
        return Map.of("greeting", "Hello World!");
    }

    @GetMapping("/object/hello")
    public Hello objectHello() {
        log.info("Got request -  object");
        return new Hello("Hello World!");
    }

    @GetMapping("/better-way/hi")
    public Hi objectHi() {
        log.info("Got request -  object");
        return new Hi("Hi World!");
    }

    @GetMapping("/object-bad-way/hello")
    public ResponseObject<Hello> oldWay() {
        log.info("Got request -  object - old way - don't do this, use ResponseBodyAdvice");
        var resp = new ResponseObject<Hello>();
        var span = tracer.currentSpan();
        if (span != null) {
            resp.setTraceId(span.context().traceId());
            resp.setSpanId(span.context().spanId());
        }

        resp.setTimestamp(System.currentTimeMillis());
        try {
            resp.setBody(new Hello("Hello World!")); //service call
            resp.setStatus(HttpStatus.OK.value());
        } catch (Exception e) {
            resp.setStatus(HttpStatus.INTERNAL_SERVER_ERROR.value());
        }

        return resp;
    }

    @GetMapping("/object-bad-way/hi")
    public ResponseObject<Hi> oldWayHi() {
        log.info("Got request -  object - old way - don't do this, use ResponseBodyAdvice");
        var resp = new ResponseObject<Hi>();
        var span = tracer.currentSpan();
        if (span != null) {
            resp.setTraceId(span.context().traceId());
            resp.setSpanId(span.context().spanId());
        }

        resp.setTimestamp(System.currentTimeMillis());
        try {
            resp.setBody(new Hi("Hello World!")); //service call
            resp.setStatus(HttpStatus.OK.value());
        } catch (Exception e) {
            resp.setStatus(HttpStatus.INTERNAL_SERVER_ERROR.value());
        }

        return resp;
    }


}


@Slf4j
@ControllerAdvice
@RequiredArgsConstructor
class ObjectResponseAdvice implements ResponseBodyAdvice<Object> {

    final Tracer tracer;
    final ObjectMapper objectMapper;

    @Override
    public boolean supports(MethodParameter returnType, Class<? extends HttpMessageConverter<?>> converterType) {
        return true;
    }

    @SneakyThrows
    @Override
    public Object beforeBodyWrite(Object body, MethodParameter returnType,
                                  MediaType selectedContentType, Class<? extends HttpMessageConverter<?>> selectedConverterType, ServerHttpRequest request, ServerHttpResponse response) {


        if (response instanceof ServletServerHttpResponse resp
                //if body is already ResponseObject  - do not convert
                && !(body instanceof ResponseObject)) {

            ObjectNode root = objectMapper.createObjectNode();
            var span = tracer.currentSpan();
            if (span != null) {
                root.put("traceId", span.context().traceId());
                root.put("spanId", span.context().spanId());
            }
            root.put("status", resp.getServletResponse().getStatus());
            if (BeanUtils.isSimpleValueType(body.getClass())) {
                root.put("body", String.valueOf(body));
            } else {
                root.set("body", objectMapper.convertValue(body, JsonNode.class));
            }
            root.put("timestamp", System.currentTimeMillis());

            if (body instanceof String) {
                // String are handled special case with StringHttpMessageConverter
                // we need to return String from this method
                return objectMapper.writeValueAsString(root);
            } else {
                return root;
            }
        }

        return body;
    }
}


@Getter
@NoArgsConstructor
@AllArgsConstructor
class Hello {
    String greeting;
}

@Getter
@NoArgsConstructor
@AllArgsConstructor
class Hi {
    String hi;
}

@Getter
@Setter
class ResponseObject<T> {
    T body;
    long timestamp;

    String traceId;
    String spanId;

    long durationMs;
    int status;
}

Run a task in a different interval during weekend using Spring Scheduler and Custom Trigger

2025-02-27T17:44:00.004+00:00

Run a task in a different interval during weekend.

Instead of defining fixed interval to run a task every 1 minute (as shown in example below) using @Scheduled, we can customize Spring Task Scheduler to schedule job with a custom trigger to run the tasks in different schedule depending on business logic.

@Scheduled(fixedRate = 1, timeUnit = TimeUnit.MINUTES)
void job1() {
     System.out.println("Running job1 - this won't run on weekend");
}

For example, we can do the following to run the task every 15 minute instead of 1 minute during weekends. Here we are registering a task job1 with TaskScheduler with a CustomTrigger.

The CustomTrigger implements Spring's Trigger interface and overrides nextExecution() method to do business logic to find the interval on which the task should run. For the example purpose we are running tasks less often (every 15 minute) during weekend.

DayOfWeek day = LocalDate.now(ZoneId.of(ZoneId.SHORT_IDS.get("CST"))).getDayOfWeek();
Duration nextSchedulePeriod = WORKDAY_INTERVAL;

/*
 * Run the task every 15 minute often during weekend
 */

if (day == DayOfWeek.SATURDAY || day == DayOfWeek.SUNDAY) {
     nextSchedulePeriod = WEEKEND_INTERVAL;
}
return new PeriodicTrigger(nextSchedulePeriod).nextExecution(ctx);


import org.springframework.beans.factory.InitializingBean;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Configuration;
import org.springframework.scheduling.TaskScheduler;
import org.springframework.scheduling.Trigger;
import org.springframework.scheduling.TriggerContext;
import org.springframework.scheduling.support.PeriodicTrigger;

import java.time.DayOfWeek;
import java.time.Duration;
import java.time.Instant;
import java.time.LocalDate;
import java.time.ZoneId;

@Configuration
class CustomTaskScheduler implements InitializingBean {

     static final Duration WORKDAY_INTERVAL = Duration.ofMinutes(1);
     static final Duration WEEKEND_INTERVAL = Duration.ofMinutes(15);

     @Autowired
     TaskScheduler taskScheduler;


     @Override
     public void afterPropertiesSet() {
          taskScheduler.schedule(this::job1, new CustomTrigger());
          // schedule more tasks
     }

     void job1() {
          System.out.println("Running job1 - this won't run on weekend");
     }


     static class CustomTrigger implements Trigger {
          /**
           * Determine the next execution time according to the given trigger context.
           */
          @Override
          public Instant nextExecution(TriggerContext ctx) {
               DayOfWeek day = LocalDate.now(ZoneId.of(ZoneId.SHORT_IDS.get("CST"))).getDayOfWeek();
               Duration nextSchedulePeriod = WORKDAY_INTERVAL;

               /*
                * Run the task every 15 minute often during weekend
                */

               if (day == DayOfWeek.SATURDAY || day == DayOfWeek.SUNDAY) {
                    nextSchedulePeriod = WEEKEND_INTERVAL;
               }
               return new PeriodicTrigger(nextSchedulePeriod).nextExecution(ctx);
          }


     }

}

Append a file into existing ZIP using Java

2025-02-27T17:15:00.000+00:00

Need to modify a text file inside a ZIP without extracting the whole archive to disk? In this post, I’m going to show you how to do exactly that with a pure‑Java approach. The snippet opens in.zip, streams through its entries, and for the one named abc.txt it reads the content, replaces key1=value1 with key1=val2, appends a timestamp, and writes the updated bytes. Every other entry is copied byte‑for‑byte unchanged into a fresh out.zip. The logic relies on java.util.zip.ZipFile for reading and ZipOutputStream for writing, completely avoiding temporary files. I’ve also included a small helper isToString that converts an InputStream to a String via a ByteArrayOutputStream. One thing to keep in mind: the current implementation loads the file’s entire content into memory, so it’s perfect for small text files. If you’re dealing with larger data, a line‑by‑line streaming variant would be safer. Just drop this code into a ZipTests class, place in.zip next to it, and run it — you’ll get out.zip with your modifications ready to use.

import java.io.ByteArrayOutputStream;
import java.io.FileOutputStream;
import java.io.InputStream;
import java.nio.charset.StandardCharsets;
import java.time.LocalDateTime;
import java.util.zip.ZipOutputStream;

public class ZipTests {

    public static void main(String[] args) throws Exception {
        var zipFile = new java.util.zip.ZipFile("in.zip");
        final var zos = new ZipOutputStream(new FileOutputStream("out.zip"));
        for (var e = zipFile.entries(); e.hasMoreElements(); ) {
            var entryIn = e.nextElement();
            System.out.println("Processing entry " + entryIn.getName());

            // Set the next entry before writing any data to it
            zos.putNextEntry(entryIn);

            if (entryIn.getName().equalsIgnoreCase("abc.txt")) {
                // Read existing content, replace a key, and append a timestamp

                String content = isToString(zipFile.getInputStream(entryIn));
                content = content.replaceAll("key1=value1", "key1=val2");
                content += LocalDateTime.now() + "\r\n";

                byte[] buf = content.getBytes();
                zos.write(buf, 0, buf.length);
            } else {
                // For all other entries, stream the bytes unchanged
                var inputStream = zipFile.getInputStream(entryIn);
                byte[] buf = new byte[9096];
                int len;
                while ((len = inputStream.read(buf)) > 0) {
                    zos.write(buf, 0, len);
                }

            }
            zos.closeEntry();
        }
        zos.close();
    }

    static String isToString(InputStream stringStream) throws Exception {
        var result = new ByteArrayOutputStream();
        byte[] buffer = new byte[1024];
        for (int length; (length = stringStream.read(buffer)) != -1; ) {
            result.write(buffer, 0, length);
        }
        return result.toString(StandardCharsets.UTF_8);
    }

}

Spring Boot - get Trace and Span ID programmatically

2025-02-27T17:08:00.001+00:00

Autowire Tracer tracer

and get traceId and spanId from current Span


Span span = tracer.currentSpan();
span.context().traceId() //trace ID
span.context().spanId() //span ID

8 puzzle solver using A* algorithm

2024-06-23T23:26:00.010+01:00

8-puzzle is a very interesting and a well known problem in the field of Artificial Intelligence. It always has been an important subject in articles, books and become a part of course material in many universities. The 8-puzzle is also known as the sliding-block puzzle or tile-puzzle and is meant for a single user. 8-puzzle consists of 8 square tiles numbered 1 through 8 and one blank space on a 3 by 3 board. Moves of the puzzle are made by sliding an adjacent tile into the position occupied by the blank space, which has the effect of exchanging the positions of the tile and blank space. Only tiles that are horizontally or vertically adjacent (not diagonally adjacent) may be moved into the blank space. The objective of the game is to start from an initial configuration and end up in a configuration which the tiles are placed in ascending number order as shown in: figure 1 below.

Figure 1 Goal state of the 8-puzzle

HOW TO PLAY

The game can be played using the arrow keys. Up arrow slides a tile up into the empty space, left arrow slides a tile left into the empty space and so on. You can choose to solve it automatically by program. It will display the animation sliding the tiles and solve the 8 puzzle in least possible moves using AI.

METHODOLOGY

According to the authors Russel and Norvig in their book titled Artificial Intelligence: A Modern Approach, the average solution for a randomly generated 8-puzzle instance is about 22 steps. This figure is obtained by estimating the branching factor which is about 3 (when the empty tile is in the middle, there are four possible moves; when it is in a corner there are two; and when it is along an edge there are three). This means that an exhaustive search to depth 22 would look at about 322 ~ 3.1 x 1010 states. By keeping track of repeated states, it is possible to cut this down by a factor of about 170,000, because there are only 9!/2 = 181,440 distinct states that are reachable.

ALGORITHM

After a preliminary investigation of the heuristic search strategies we were able to figure out that A* algorithm is the best for the 8-puzzle problem. A* is the most widely used form of best first search algorithm which is an instance of Tree-Search or Graph-Search where a best node is expanded on the basis of an evaluation function f(n). Here, the evaluation function of each node is calculated as a sum of two functions g(n) and h(n) where, g(n) refers to the cost to reach the node n while h(n) is the cost to get from node n to the goal. A* algorithm is both optimal and complete. It is optimal in that sense h(n) is admissible and is never overestimated

to reach the goal and it is complete in that sense it guarantees to reach a solution whenever there is one.

The following pseudo code describes the A* algorithm:

function A*(start,goal)

closedset := the empty set // The set of nodes already evaluated.

openset := set containing the initial node // The set of tentative nodes to be evaluated.

g_score[start] := 0 // Distance from start along optimal path.

h_score[start] := heuristic_estimate_of_distance(start, goal)

f_score[start] := h_score[start] // Estimated total distance from start to goal through y.

while openset is not empty

x := the node in openset having the lowest f_score[] value

if x = goal

return reconstruct_path(came_from[goal])

remove x from openset

add x to closedset

foreach y in neighbor_nodes(x)

if y in closedset

continue

tentative_g_score := g_score[x] + dist_between(x,y)

if y not in openset

add y to openset

tentative_is_better := true

elseif tentative_g_score < g_score[y]

tentative_is_better := true

else

tentative_is_better := false

if tentative_is_better = true

came_from[y] := x

g_score[y] := tentative_g_score

h_score[y] := heuristic_estimate_of_distance(y, goal)

f_score[y] := g_score[y] + h_score[y]

return failure

function reconstruct_path(current_node)

if came_from[current_node] is set

p = reconstruct_path(came_from[current_node])

return (p + current_node)

else

return current_node

REFERENCE

1. Rich and Knight, Artificial Intelligence.

2. Russell and Norvig, Artificial Intelligence: A Modern approach,
3. A* search algorithm - Wikipedia, the free encyclopedia
4. Description and a solution strategy for the 8-puzzle from http://www.8puzzle.com/
5. G. Novak, CS 381K: Heuristic Search: 8 Puzzle, 26 Sep 07
6. An appealing Java applet from www.permadi.com/java/puzzle8/

JSP basics - Java Server Pages

2024-06-23T23:24:00.001+01:00

The JSP - Java Server Pages

JSP extension of the servlet technology which offers both scripting ( as in HTML) as well as programming (as in Servlets)
When a JSP page is requested, the JSP container ( also called page compiler) compiles the jsp page into a servlet class.
The JSP API that handles all the JSP technology has been bundled under the following two packages:

javax.servlet.jsp
javax.servlet.jsp.tagext

JSP Syntax

A JSP page is all about JSP tags and some template data ( such as HTML tags). That's pretty much of it. It always feels good learning about JSP as we get to see the very well-know HTML tags (I presumed that you already know HTML at this point).

JSP consists of three types of elements.

Directive elements
Scripting elements
Action elements

DIRECTIVES

<%@ directiveName (attributeName="atrributeValue") %>

These are the messages/information to the JSP container on how it should translate the JSP page into the corresponding servlet.

Again, there are three types of directives:

Page directives
Include directives
Tag library directives

1. Page Directive
<%@ page (attributeName="atrributeValue") %>

You might have encountered some "import" statements at the beginning of some JSP pages. Those import statements falls under this category. E.g.

<%@ page import="java.util.Date, java.util.Enumeration" language="java" %>
where,
page => represents directiveName
import/language => represents attributeName
and the values enclosed by quotes represents atrributeValue

The following is the list of available Page directive attributes:

Attribute	Value Type	Default Value
language	Scripting language name	"java"
info	String	Depends on the JSP container
contentType	MIME type, character set	"text/html;charset=ISO-8859-1"
extends	Class name	None
import	Fully qualified class name or package name	None
buffer	Buffer size or false	8Kb
autoFlush	Boolean	"true"
session	Boolean	"true"
isThreadSafe	Boolean	"true"
errorPage	URL	None
isErrorPage	Boolean	"false"

NOTE:

Except for the import attribute, JSP does not allow to repeat the same attribute within a page directive or in multiple directives on the same page.

Page Attributes a little in-depth:

language

<%@ page language="java" %>
The only supported language by Tomcat JSP Container
Other JSP containers might accept different languages

info

<%@ page info="any string here" %>
Can be retrieved by calling the method getServletInfo() from anywhere withing the page

contentType

<%@ page contentType="application/json; charset=UTF-8" %>
Defines MIME type of the HTTP response sent to the client

extends

<%@ page extends="yourClass" %>
Defines the parent class that will be inherited by the generated servlet of the current page
This attribute is less common

import

<%@ page import="java.io.*" %>
One of the most common attributes used
Same as we do in java classes/interfaces
By default, tomcat imports the following packages:

javax.servlet.*
javax.servlet.http.*
javax.servlet.jsp.*
javax.servlet.jsp.tagext.*
org.apache.jasper.runtime.*

buffer

<%@ page buffer="none" %>
<%@ page buffer="20kb" %>
<%@ page buffer="20" %>
buffer="20" is the same as "20kb"
But it's up to the JSP container to use its discretion to increase the buffer in order for the improved performance

autoFlush

<%@ page autoFlush="false" %>
If true, the JSP container automatically flushes the buffer when it's full.
If false, the buffer can be flushed manually by the following statement:

out.flush()

session

<%@ page session="true" %>
By default, the session is set "true", meaning the JSP page takes part in session management
It is wise and strongly advised not to set it true unless you specifically require it because this consumes resources.

isThreadSafe

<%@ page isThreadSafe="true" %>
True indicates that the simultaneous access to this page is safe
False indicates that the simultaneous access to this page is not safe. In that case, the JSP container puts multiple requests in a queue and serves them only one at a time.

errorPage

<%@ page errorPage="MyErrorPage.jsp" %>
Indicates the error page which is displayed if an uncaught exception occurs in the current page
The error page must have the page attribute isErrorPage="true"

isErrorPage

<%@ page isErrorPage="true" %>
If true, then only be set as an error page in other JSP pages
If true, this page has an access to the exception implicit object

2. Include directives

<%@ include file="includes/Footer.html" %>

As the name suggest, Include Directive enables us to include the contents of other files in the current JSP page.
The included page can be static HTML page as well as dynamic JSP page.
Very commonly used to include Header page, Footer page or a page containing import statements and so on.

2. Taglib directives

The taglib, or tag library, directive can be used to extend JSP functionality. It's a broad topic so it's not covered here at this moment. It will be covered under it's own topic later soon.

SCRIPTING ELEMENTS

Scripting elements allow you to insert Java code in your JSP pages. There are three types of scripting elements:

Scriptlets
Declarations
Expressions

1. Scriptlets

<% ... %>

Syntax looks similar to Directives. But don't get confused, Directives starts with <%@ i.e. <%@ ... %>

try {

Class.forName("com.mysql.jdbc.Driver");

System.out.println("JDBC driver loaded");

}

catch (ClassNotFoundException e) {

System.out.println(e.toString());

}

...

out.println("You can do anything here");

String str = "some string";

str = str + " string concatenation";

out.println( str );

2. Declarations

<%! ... %>

Used to declare methods and variables that can be used from any point in the JSP page.
Can appear anywhere throughout the page. For instance, a method declaration can appear above a page directive that imports a class, even though the class is used in the method.

<%!

String getSystemTime() {

return Calendar.getInstance().getTime().toString();

}

<%@ page import="java.util.Calendar" %>

out.println("Current Time: " + getSystemTime());

3. Expressions
<%= ... %>

Expressions get evaluated when the JSP page is requested and their results are converted into a String and fed to the print method of the out implicit object.
If the result cannot be converted into a String, an error will be raised at translation time. If this is not detected at translation time, at request-processing time, a ClassCastException will be raised.
Don't need to add a semicolon at the end of an expression

Below is the two equivalent statements:

<%= java.util.Calendar.getInstance().getTime() %>

<% out.print(java.util.Calendar.getInstance().getTime()); %>

How to reset “Replace Toner” warning on Brother MFC-L2710DW Printer

2023-07-09T20:25:00.002+01:00

How to reset “Replace Toner” warning on Brother MFC-L2710DW Printer and print ~100 more pages without replacing the toner!

Open the front cover.
Press Clear and Stop/Exit button simultaneously and press Clear button once.
It will show the following on the display:
Reset Menu

K.TNR-STR

Press UP arrow once. It will show “K.TNR-HC”. Press OK.
Press UP arrow for reset.
Close the cover. DONE!

NOW ENJOY!

Java PDF to Image Conversion using PDFBox

2023-04-23T20:01:00.003+01:00

Here are few snippets of code that you can use to convert a PDF file to images eg: tiff, png, multi-page tiff. It uses a open source library PDFBox version 3

The Apache PDFBox^® library is an open source Java tool for working with PDF documents. This project allows creation of new PDF documents, manipulation of existing documents and the ability to extract content from documents.

PDFBox comes with following features:

Extract Unicode text from PDF files.
Split a single PDF into many files or merge multiple PDF files.
Extract data from PDF forms or fill a PDF form.
Validate PDF files against the PDF/A-1b standard.
Print a PDF file using the standard Java printing API.
Save PDFs as image files, such as PNG or JPEG.
Create a PDF from scratch, with embedded fonts and images.

Convert PDF to PNG/JPG/BMP etc:

public static void convertToSeparateImageFiles(File pdf, String type) throws Exception {
    int DPI = 300;
    ImageType IMAGE_TYPE = ImageType.RGB;//This can be GRAY,ARGB,BINARY, BGR

    try (PDDocument document = Loader.loadPDF(pdf)) {
        PDFRenderer pdfRenderer = new PDFRenderer(document);
        for (int page = 0; page < document.getNumberOfPages(); page++) {
            BufferedImage bim = pdfRenderer.renderImageWithDPI(page, DPI, IMAGE_TYPE);

            File outputFile = new File(pdf.getAbsoluteFile().getParent() + 
                    File.separator + pdf.getName() + "-P-" + page + "." + type);
            ImageIO.write(bim, type, outputFile);
        }
    }
}

Convert PDF to PNG/JPG/BMP etc with compression

public static void convertToSeparateImageFilesWithCompression(File pdf, String type) throws Exception {
    int DPI = 300;
    ImageType IMAGE_TYPE = ImageType.RGB;//This can be GRAY,ARGB,BINARY, BGR

    try (PDDocument document = Loader.loadPDF(pdf)) {
        ImageWriter writer = null;
        try {
            writer = ImageIO.getImageWritersByFormatName(type).next();

            ImageWriteParam params = writer.getDefaultWriteParam();
            params.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
            params.setCompressionQuality(0.6f);

            PDFRenderer pdfRenderer = new PDFRenderer(document);

            for (int page = 0; page < document.getNumberOfPages(); page++) {
                BufferedImage bim = pdfRenderer.renderImageWithDPI(page, DPI, IMAGE_TYPE);

                File outputFile = new File(pdf.getAbsoluteFile().getParent() +
                        File.separator + pdf.getName() + "-compressed-P-" + page + "." + type);
                ImageOutputStream outputStream = new FileImageOutputStream(outputFile);
                writer.setOutput(outputStream);

                writer.write(null, new IIOImage(bim, null, null), params);
            }
        } finally {
            if (writer != null) {
                writer.dispose();
            }
        }
    }
}

Convert PDF to single page tiff files

public static void convertToSinglePageTiffs(File pdf) throws Exception {
    int DPI = 300;
    ImageType IMAGE_TYPE = ImageType.BINARY;//This can be GRAY,ARGB,BINARY, BGR

    try (PDDocument document = Loader.loadPDF(pdf)) {

        ImageWriter writer = null;
        try {
            writer = ImageIO.getImageWritersByFormatName("tiff").next();

            ImageWriteParam params = writer.getDefaultWriteParam();
            params.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
            // Compression Types: None, PackBits, ZLib, Deflate, LZW, JPEG and CCITT
            params.setCompressionType("LZW");
            params.setCompressionQuality(0.8f);

            PDFRenderer pdfRenderer = new PDFRenderer(document);

            for (int page = 0; page < document.getNumberOfPages(); page++) {
                BufferedImage bim = pdfRenderer.renderImageWithDPI(page, DPI, IMAGE_TYPE);

                File outputFile = new File(pdf.getAbsoluteFile().getParent() +
                        File.separator + pdf.getName() + "-compressed-P-" + page + ".tif");
                ImageOutputStream outputStream = new FileImageOutputStream(outputFile);
                writer.setOutput(outputStream);
                writer.write(null, new IIOImage(bim, null, null), params);
            }
        } finally {
            if (writer != null) {
                writer.dispose();
            }
        }
    }
}

Convert PDF to a multi-page tiff file

public static void convertToMultipageTiff(File pdf, File outputTiff) throws Exception {
    int DPI = 300;
    ImageType IMAGE_TYPE = ImageType.GRAY;//This can be GRAY,ARGB,BINARY, BGR

    try (PDDocument document = Loader.loadPDF(pdf)) {
        try (ImageOutputStream ios = ImageIO.createImageOutputStream(outputTiff)) {

            ImageWriter writer = null;
            try {
                writer = ImageIO.getImageWritersByFormatName("tiff").next();
                writer.setOutput(ios);
                writer.prepareWriteSequence(null);

                ImageWriteParam params = writer.getDefaultWriteParam();
                params.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
                // Compression Types: None, PackBits, ZLib, Deflate, LZW, JPEG and CCITT
                params.setCompressionType("LZW");
                params.setCompressionQuality(0.8f);

                PDFRenderer pdfRenderer = new PDFRenderer(document);

                for (int page = 0; page < document.getNumberOfPages(); page++) {
                    BufferedImage bim = pdfRenderer.renderImageWithDPI(page, DPI, IMAGE_TYPE);

                    IIOMetadata metadata = writer.getDefaultImageMetadata(new ImageTypeSpecifier(bim), params);
                    writer.writeToSequence(new IIOImage(bim, null, metadata), params);
                }
            } finally {
                if (writer != null) {
                    writer.dispose();
                }
            }
        }
    }
}

Full code:

Uses dependency:

<dependency>
    <groupId>org.apache.pdfbox</groupId>
    <artifactId>pdfbox</artifactId>
    <version>3.0.0-RC1</version>
</dependency>

package pdf;

import org.apache.pdfbox.Loader;
import org.apache.pdfbox.pdmodel.PDDocument;
import org.apache.pdfbox.rendering.ImageType;
import org.apache.pdfbox.rendering.PDFRenderer;

import javax.imageio.*;
import javax.imageio.metadata.IIOMetadata;
import javax.imageio.stream.FileImageOutputStream;
import javax.imageio.stream.ImageOutputStream;
import java.awt.image.BufferedImage;
import java.io.File;

public class PDFUtils {
public static void main(String[] args) throws Exception {
    File pdf = new File("test.pdf");
    convertToSeparateImageFiles(pdf, "png");
    convertToSeparateImageFilesWithCompression(pdf, "jpg");

    //tiff
    convertToSinglePageTiffs(pdf);
    convertToMultipageTiff(pdf, new File(pdf.getAbsoluteFile().getParent() +
            File.separator + pdf.getName() + "multi-page.tif"));

}

public static void convertToSeparateImageFiles(File pdf, String type) throws Exception {
    int DPI = 300;
    ImageType IMAGE_TYPE = ImageType.RGB;//This can be GRAY,ARGB,BINARY, BGR

    try (PDDocument document = Loader.loadPDF(pdf)) {
        PDFRenderer pdfRenderer = new PDFRenderer(document);
        for (int page = 0; page < document.getNumberOfPages(); page++) {
            BufferedImage bim = pdfRenderer.renderImageWithDPI(page, DPI, IMAGE_TYPE);

            File outputFile = new File(pdf.getAbsoluteFile().getParent() +
                    File.separator + pdf.getName() + "-P-" + page + "." + type);
            ImageIO.write(bim, type, outputFile);
        }
    }
}

public static void convertToSeparateImageFilesWithCompression(File pdf, String type) throws Exception {
    int DPI = 300;
    ImageType IMAGE_TYPE = ImageType.RGB;//This can be GRAY,ARGB,BINARY, BGR

    try (PDDocument document = Loader.loadPDF(pdf)) {
        ImageWriter writer = null;
        try {
            writer = ImageIO.getImageWritersByFormatName(type).next();

            ImageWriteParam params = writer.getDefaultWriteParam();
            params.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
            params.setCompressionQuality(0.6f);

            PDFRenderer pdfRenderer = new PDFRenderer(document);

            for (int page = 0; page < document.getNumberOfPages(); page++) {
                BufferedImage bim = pdfRenderer.renderImageWithDPI(page, DPI, IMAGE_TYPE);

                File outputFile = new File(pdf.getAbsoluteFile().getParent() +
                        File.separator + pdf.getName() + "-compressed-P-" + page + "." + type);
                ImageOutputStream outputStream = new FileImageOutputStream(outputFile);
                writer.setOutput(outputStream);

                writer.write(null, new IIOImage(bim, null, null), params);
            }
        } finally {
            if (writer != null) {
                writer.dispose();
            }
        }
    }
}

public static void convertToSinglePageTiffs(File pdf) throws Exception {
    int DPI = 300;
    ImageType IMAGE_TYPE = ImageType.BINARY;//This can be GRAY,ARGB,BINARY, BGR

    try (PDDocument document = Loader.loadPDF(pdf)) {

        ImageWriter writer = null;
        try {
            writer = ImageIO.getImageWritersByFormatName("tiff").next();

            ImageWriteParam params = writer.getDefaultWriteParam();
            params.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
            // Compression Types: None, PackBits, ZLib, Deflate, LZW, JPEG and CCITT
            params.setCompressionType("LZW");
            params.setCompressionQuality(0.8f);

            PDFRenderer pdfRenderer = new PDFRenderer(document);

            for (int page = 0; page < document.getNumberOfPages(); page++) {
                BufferedImage bim = pdfRenderer.renderImageWithDPI(page, DPI, IMAGE_TYPE);

                File outputFile = new File(pdf.getAbsoluteFile().getParent() +
                        File.separator + pdf.getName() + "-compressed-P-" + page + ".tif");
                ImageOutputStream outputStream = new FileImageOutputStream(outputFile);
                writer.setOutput(outputStream);
                writer.write(null, new IIOImage(bim, null, null), params);
            }
        } finally {
            if (writer != null) {
                writer.dispose();
            }
        }
    }
}

public static void convertToMultipageTiff(File pdf, File outputTiff) throws Exception {
    int DPI = 300;
    ImageType IMAGE_TYPE = ImageType.GRAY;//This can be GRAY,ARGB,BINARY, BGR

    try (PDDocument document = Loader.loadPDF(pdf)) {
        try (ImageOutputStream ios = ImageIO.createImageOutputStream(outputTiff)) {

            ImageWriter writer = null;
            try {
                writer = ImageIO.getImageWritersByFormatName("tiff").next();
                writer.setOutput(ios);
                writer.prepareWriteSequence(null);

                ImageWriteParam params = writer.getDefaultWriteParam();
                params.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
                // Compression Types: None, PackBits, ZLib, Deflate, LZW, JPEG and CCITT
                params.setCompressionType("LZW");
                params.setCompressionQuality(0.8f);

                PDFRenderer pdfRenderer = new PDFRenderer(document);

                for (int page = 0; page < document.getNumberOfPages(); page++) {
                    BufferedImage bim = pdfRenderer.renderImageWithDPI(page, DPI, IMAGE_TYPE);

                    IIOMetadata metadata = writer.getDefaultImageMetadata(new ImageTypeSpecifier(bim), params);
                    writer.writeToSequence(new IIOImage(bim, null, metadata), params);
                }
            } finally {
                if (writer != null) {
                    writer.dispose();
                }
            }
        }
    }
}
}

git reset/revert to previous commit

2021-12-02T00:57:00.003+00:00

Sometimes we "accidentally" merge something that's not ready for release/qa and need to rollback/reset/revert the commits to a cleaner state.

Here's how you can safely reset your git to previous commit:

1) find the older commit id to where you want to reset.

2) do git status to confirm there are no uncommitted changes on the current branch

3) reset to a commit,

git reset --hard COMMIT_ID
git reset HEAD@{1}
git add .
git commit -m "reverting to commit COMMIT_ID"

4) cherry pick or patch any other commit that you like to add

How to make integration tests faster without @DirtiesContext

2021-07-17T01:10:00.006+01:00

If your only excuse to use @DirtiesContext is to re-initialize database between tests, then this blog post is for you.

Spring's @DirtiesContext is very useful to make your integration tests faster by indicating the underlying Spring ApplicationContext is modified and forcing it to reload the context (not the whole application) between tests.

This is particularly useful when we want to reset the state of database between tests. This allows us to group many tests together in a same class so that we can easily share some test data, assertions etc. So your test code would look this this:

@SpringBootTest
@DirtiesContext(classMode = AFTER_EACH_TEST_METHOD)
class SomeTest {

    @Autowired SomeService serv;
    @Autowired DataCreator dc;

    @Test
    void someTest1() {
        //prepare data
        dc.initData();
        //run test
        serv.modifySomeData();
        //verify 
    }

    @Test
    void someTest2() {
        //prepare data
        dc.initData(2);
        //run test
        serv.modifyAnotherData();
        serv.doSomethingElse();
        //verify 
    }
}

Problem with @DirtiesContext

This has one major flaw though. By resetting the ApplicationContext, it would also drop all the databases and need to re-create them after every test. So, if the only reason to use @DirtiesContext is to reset the database, then there's a better way of doing this.

Is deleting records from all table not a good solution?

Correct. Deleting records is still a slow operation. When you have a good amount to test data, the @DirtiesContext can sometimes becomes faster than deleting the records one by one. Also, there's referential integrity between tables that enforces you to follow a series of deletes to first delete records from child tables and go up.

Table Truncate to the rescue

Truncate (truncate table X) is faster way to delete records from database than deleting records. If we already know the list of table and join tables then we can loop through them and execute the TRUNCATE TABLE command. One advantage of this approach is that we can skip truncating some lookup tables that will always have constant records.

How to Truncate H2 Tables:

Note that before we execute the TRUNCATE TABLE we should disable the referential integrity.

em.createNativeQuery("SET REFERENTIAL_INTEGRITY FALSE").executeUpdate();
for (String t : tableNames) {
    em.createNativeQuery("TRUNCATE TABLE " + t ).executeUpdate();
}
em.createNativeQuery("SET REFERENTIAL_INTEGRITY TRUE").executeUpdate();

Integrating everything together (Sample App @ GitHub):

TestDataManager to grab list of tables, truncate and populate the test data:

import gt.app.DataCreator;
import gt.app.config.MetadataExtractorIntegrator;
import lombok.RequiredArgsConstructor;
import org.hibernate.boot.Metadata;
import org.hibernate.mapping.Collection;
import org.hibernate.mapping.PersistentClass;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import javax.persistence.EntityManager;
import java.util.ArrayList;
import java.util.List;

@Service
@RequiredArgsConstructor
public class TestDataManager implements InitializingBean {
    final EntityManager em;
    final DataCreator dataCreator;

    private final List<String> tableNames = new ArrayList<>(); //shared

    @Override
    public void afterPropertiesSet() {
        Metadata metadata = MetadataExtractorIntegrator.INSTANCE.getMetadata();

        for (Collection persistentClass : metadata.getCollectionBindings()) {
            tableNames.add(persistentClass.getCollectionTable().getExportIdentifier());
        }

        for (PersistentClass persistentClass : metadata.getEntityBindings()) {
            tableNames.add(persistentClass.getTable().getExportIdentifier());
        }
    }

    @Transactional
    public void truncateTablesAndRecreate() {
        truncateTables();
        dataCreator.initData();
    }

    void truncateTables() {
        em.createNativeQuery("SET REFERENTIAL_INTEGRITY FALSE").executeUpdate();
        for (String tableName : tableNames) {
            em.createNativeQuery("TRUNCATE TABLE " + tableName).executeUpdate();
        }
        em.createNativeQuery("SET REFERENTIAL_INTEGRITY TRUE").executeUpdate();
    }
}

Call the truncateTablesAndRecreate() @BeforeEach test

@SpringBootTest
class WebAppIT {

    @Autowired
    TestDataManager tdm;

    @BeforeEach
    void resetDB(){
        tdm.truncateTablesAndRecreate();
    }

This is awesome, how about other databases?

To get a List of tables: You can rely on Hibernate's Metadata to grab list of table/join tables.

Truncate command: Each database has different command to set the referential integrity and truncate. This above example is for H2.

You can do the following for MySQL


//for MySQL:
em.createNativeQuery("SET @@foreign_key_checks = 0").executeUpdate();
for (String tableName : tableNames) {
    em.createNativeQuery("TRUNCATE TABLE " + tableName).executeUpdate();
}
em.createNativeQuery("SET @@foreign_key_checks = 1").executeUpdate();

For other populate databases, you can take reference from Hibernate's Test code itself. They are available at: Hibernate GitHub. The *Cleaner classes have code snippet that describes how to perform truncate on each database.

How fast the tests ran after this update?

Very fast! In a big application (Spring Boot, H2) with 62 tables and 315 tests that were using @DirtiesContext, we reduced our test execution time from 18 minutes to 4minutes.

Full working example is available at this sample app.

JPA/Hibernate get find all Table and Column metadata

2021-07-16T23:49:00.003+01:00

How to use Hibernate Metadata to find All columns and tables

Getting the Hibernate's Metadata object into the Spring application is tricky. Luckily, Hibernate Provides an Integrator API (org.hibernate.integrator.spi.Integrator) that we can use to customize/interact with Hibernate. Its the same API that Caching, Bean Validation etc library uses to integrate with Hibernate.

Also, Spring Boot provides HibernatePropertiesCustomizer to link the 'hibernate.integrator_provider' property to Integrator implementation.

Here's how we can configure the Hibernate Integrator to read metadata.

Step 1) create a extractor implementation

This class is a singleton class and does absolutely nothing other than exposing the Metadata and Database. Since this is singleton this class and the database, metadata objects can be statically accessed using MetadataExtractorIntegrator.INSTANCE

import lombok.Data;
import org.hibernate.boot.Metadata;
import org.hibernate.boot.model.relational.Database;
import org.hibernate.engine.spi.SessionFactoryImplementor;
import org.hibernate.integrator.spi.Integrator;
import org.hibernate.service.spi.SessionFactoryServiceRegistry;

@Data
public class MetadataExtractorIntegrator implements Integrator {

    public static final MetadataExtractorIntegrator INSTANCE = 
                            new MetadataExtractorIntegrator();
    private Database database;
    private Metadata metadata;

    @Override
    public void integrate(Metadata metadata, SessionFactoryImplementor sf, 
                          SessionFactoryServiceRegistry sr) {
        this.database = metadata.getDatabase();
        this.metadata = metadata;
    }

    @Override
    public void disintegrate(SessionFactoryImplementor sf, 
                             SessionFactoryServiceRegistry sr) {
    }
}

Step 2) Register the Spring Hibernate Customizer


import org.hibernate.jpa.boot.spi.IntegratorProvider;
import org.springframework.boot.autoconfigure.orm.jpa.HibernatePropertiesCustomizer;
import org.springframework.context.annotation.Configuration;

import java.util.List;
import java.util.Map;

@Configuration
public class HibernateConfig implements HibernatePropertiesCustomizer {
    @Override
    public void customize(Map<String, Object> hibernateProps) {
        hibernateProps.put("hibernate.integrator_provider",
            (IntegratorProvider) () -> List.of(MetadataExtractorIntegrator.INSTANCE));
    }
}

Step 3) Use MetadataExtractorIntegrator.metadata to extract the metadata

This is a simple Spring Component that uses Metadata.getCollectionBindings and Metadata.getEntityBindings to extract the tables, columns, PK and type

import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.hibernate.boot.Metadata;
import org.hibernate.mapping.*;
import org.springframework.beans.factory.InitializingBean;
import org.springframework.stereotype.Component;

import javax.persistence.EntityManager;
import java.util.Iterator;

@Component
@RequiredArgsConstructor
@Slf4j
public class DBMetadataReader implements InitializingBean {
    final EntityManager em;

    @Override
    public void afterPropertiesSet() {

        Metadata metadata = MetadataExtractorIntegrator.INSTANCE.getMetadata();

        //Collection tables
        for (Collection c : metadata.getCollectionBindings()) {
            log.info("Collection table: {}", c.getCollectionTable().getQualifiedTableName());
            for (Iterator<Column> it = c.getCollectionTable().getColumnIterator();
                 it.hasNext(); ) {
                Column property = it.next();
                log.info("   {}   {} ", property.getName(), property.getSqlType());
            }
        }

        //all entities
        for (PersistentClass pc : metadata.getEntityBindings()) {
            Table table = pc.getTable();

            log.info("Entity: {} - {}", pc.getClassName(), table.getName());

            KeyValue identifier = pc.getIdentifier();

            //PK
            for (Iterator<Selectable> it = identifier.getColumnIterator();
                 it.hasNext(); ) {
                Column column = (Column) it.next();
                log.info("    PK: {}  {}", column.getName(), column.getSqlType());
            }

            //property/columns
            for (Iterator it = pc.getPropertyIterator();
                 it.hasNext(); ) {
                Property property = (Property) it.next();

                for (Iterator columnIterator = property.getColumnIterator();
                     columnIterator.hasNext(); ) {
                    Column column = (Column) columnIterator.next();
                    log.info("    {}  {}", column.getName(), column.getSqlType());
                }
            }
        }
    }
}

Example Project:

Checkout my sample github project and the source for working example

SpringFox Swagger with Groovy - fixing slow startup / heap space error

2021-07-08T04:44:00.005+01:00

Story of how we reduced app startup time by 20x and heap usage by 7x

Few months ago, we started developing a Spring Boot app in Groovy. It is a typical app with ton of CRUD logic and few REST endpoints. It also had a Swagger UI configured with SpringFox Swagger. Though it was taking ~35 seconds to start and taking ~700MB heap space, no-one in the team really cared about the slowness and memory usage of the application.

As our application grew bigger, we added more DB tables and endpoints which resulted in further slowness and required more heap space. It was ~3 minutes startup with almost 1.4GB heap at its worst state. Again no-one really bothered to fix it... until the application randomly failed to start and started crashing randomly with OutOfMemoryError.

Problem Identification: Thread Dump using IntelliJ

The IntelliJ thread-dump showing the main thread always stuck at springfox

I started the application in debug mode in IntelliJ and took thread dump several times to see what's the main thread is doing. I found that in all thread dumps, the main thread was stuck around springfox.documentation.spring.web.readers.parameter.ModelAttributeParameterExpander.expand() method.

So, I dig into the ModelAttributeParameterExpander#expand() method was able to quickly confirm that it was trying to expand the fields from the @ModelAttribute to render into the Swagger UI - which is exposed in a JSON endpoint host:port/v3/api-docs.

Once the application started (after about 3 mins), I opened up the host:port/v3/api-docs endpoint locally and amazed by the size of JSON response. It WAS 1240MB! That explained why Swagger UI used to take longer.

Problem Isolation:

To isolate the problem, I commented out all the endpoints that's using @ModelAttribute and just like I expected, the app started within 9 seconds, took about 200MB heap, the swagger UI loaded within one second, the host:port/v3/api-docs endpoint response was about 20KB.

@GetMapping("/test")
void test(@ModelAttribute A a) { //commented out all the endpoints to isolate problem

Then I dig through the code inside ModelAttributeParameterExpander#expand() and I found that its collecting all the fields and properties inside the @ModelAttribute class and recursively calls the expand() method for all the sub-fields and properties.

public List<Compatibility<Parameter, RequestParameter>> expand(ExpansionContext context) {
    List<Compatibility<Parameter, RequestParameter>> parameters = new ArrayList();
    Set<PropertyDescriptor> propertyDescriptors = this.propertyDescriptors(context.getParamType().getErasedType());
    Map<Method, PropertyDescriptor> propertyLookupByGetter = this.propertyDescriptorsByMethod(context.getParamType().getErasedType(), propertyDescriptors);
    Iterable<ResolvedMethod> getters = (Iterable)this.accessors.in(context.getParamType()).stream().filter(this.onlyValidGetters(propertyLookupByGetter.keySet())).collect(Collectors.toList());
    ... 
    Stream<ModelAttributeField> collectionTypes = attributes.stream().filter(this.isCollection().and(this.recursiveCollectionItemType(context.getParamType()).negate()));
    collectionTypes.forEachOrdered((each) -> {
         ....
         parameters.addAll(this.expand(childContext)); //nested

I dig further and found that it was grabing the getMetaClass method generated by Groovy and recursively looking at all the get* methods and the parameters inside MetaClass class.

public static class MyClass implements GroovyObject {
    //..fields

    @Generated
    @Internal
    @Transient
    public MetaClass getMetaClass() {  //this was treated as class property

MetaClass: it contains several get* method. All of them were processed by Swagger

public interface MetaClass extends MetaObjectProtocol {
    Object invokeMethod(Class var1, Object var2, String var3, Object[] var4, boolean var5, boolean var6);

    Object getProperty(Class var1, Object var2, String var3, boolean var4, boolean var5);

    void setProperty(Class var1, Object var2, String var3, Object var4, boolean var5, boolean var6);

    Object invokeMissingMethod(Object var1, String var2, Object[] var3);

    Object invokeMissingProperty(Object var1, String var2, Object var3, boolean var4);

    Object getAttribute(Class var1, Object var2, String var3, boolean var4);

    void setAttribute(Class var1, Object var2, String var3, Object var4, boolean var5, boolean var6);

    void initialize();

    List<MetaProperty> getProperties();

    List<MetaMethod> getMethods();

    ClassNode getClassNode();

    List<MetaMethod> getMetaMethods();

    int selectConstructorAndTransformArguments(int var1, Object[] var2);

    MetaMethod pickMethod(String var1, Class[] var2);
}

Solution:

I found that there were few discussions already in springfox GitHub project and solution was also discussed. The solution is to configure the Docket object to ignore MetaClass class using ignoredParameterTypes() method:

   @Bean
    Docket docket(){
        new Docket(DocumentationType.OAS_30)
                .ignoredParameterTypes(MetaClass)
    }

}

Now the application takes about 9 seconds to start and takes about 200MB heap space. That was a great reduction from 3min/1.4GB.

Reproducible example:

The following simple app was taking 10 seconds to start, the http://localhost:8080/v3/api-docs returns 58.5MB JSON response. Once I comment out the test method and rerun it just takes 1.7 seconds. Also, the http://localhost:8080/v3/api-docs returns 5KB JSON response.

package gt.swagger.demo

import org.springframework.boot.SpringApplication
import org.springframework.boot.autoconfigure.SpringBootApplication
import org.springframework.web.bind.annotation.*
import springfox.documentation.swagger2.annotations.EnableSwagger2

@SpringBootApplication
@EnableSwagger2
class SwaggerTestApp {
    static void main(String[] args) {
        SpringApplication.run(SwaggerTestApp, args)
    }
}

@RestController
class Controller {

    @GetMapping("/test")
    void test(@ModelAttribute A a) {
    }

    static class A {
        String a
    }
}

When I add more endpoints with @ModelAttribute or when I nest the 'A' class with class B, the application starts taking a lot of time to start and takes up more heap space

static class A {
    String a
    B b1, b2, b3, b4, b5 ,b6, b7, b8, b9
}

static class B {
    String b
}

The problem can be solved by configuring the following bean:

@Configuration
class SwaggerConfig {

    @Bean
    Docket docket(){
        new Docket(DocumentationType.OAS_30)
                .ignoredParameterTypes(MetaClass)
    }

}

POM.xml:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.5.2</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <groupId>gt.swagg</groupId>
    <artifactId>sb25-swagger3</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <packaging>jar</packaging>

    <properties>
        <java.version>11</java.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>io.springfox</groupId>
            <artifactId>springfox-boot-starter</artifactId>
            <version>3.0.0</version>
        </dependency>
        <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy</artifactId>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
            <plugin>
                <groupId>org.codehaus.gmavenplus</groupId>
                <artifactId>gmavenplus-plugin</artifactId>
                <version>1.11.0</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>addSources</goal>
                            <goal>addTestSources</goal>
                            <goal>generateStubs</goal>
                            <goal>compile</goal>
                            <goal>generateTestStubs</goal>
                            <goal>compileTests</goal>
                            <goal>removeStubs</goal>
                            <goal>removeTestStubs</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</project>

Lesson learned:

- Pay attention on why your application is starting slow. Even a small mis-configuration like this might use up lots of resources

- Developer hour cost $$$. Make sure developers are not burning $$$ on non-trivial things like the slow application start

- Focus on how to increase developer productivity. I have seen devs compiling the whole project after every change to test it. Watch/educate developers to see if they are using the tools correctly

- Java/JVM is fast. Like every other programming language, developers can misuse/misconfigure it to make it slow

- etc

GIT write useful commit messages

2021-07-02T19:12:00.003+01:00

What's harder than choosing a variable name? IMO its composing a perfect code comment and commit message. Today we will discuss some bad commit messages, why they are bad and what we can do to improve those?

You made all the code updates, wrote tests and now its time to commit them with a commit message. Is "Code Updated" a sufficient? What about "Issue fixed"? Just imagine yourself reading the commit message some time later. Just like code comment, commit message should add context about why the code update was necessary?

A good commit message helps a future developer(it might be you) to reestablish the context around a piece of code whenever the developer needs to dig through the history to find out why the code was changed. It also helps the code reviewer to what to expect on the code.

Unless your team follows squash merge (where all the individual commits in the PR are combined and the person merging the PR can put a single/meaningful commit message) you should pay extra attention when choosing. Commit messages like the following add no value. A good developer should never write these kind of commit messages.

Bad commit messages(taken from real life examples):

issue fix
more changes
logic updated
updated code again
added import function
updated dialog box UI
deleted column

Good practices:

Describe why the code was updated?

"Issue fix" doesn't indicate which issue number and what was the cause of issue? "Logic updated" is super obvious and serves no purpose. "updated dialog box UI" doesn't indicate which dialog box and why it was updated. "added import function" doesn't indicate which data type does it import?

Refer the Issue/Jira/Story number

All the code changes should be followed by a Jira/Story created by someone. Noone should just go ahead and make a arbitrary code change. Most of the git providers (github, bitbucket, gitlab etc) support hyperlinking of Jira/Issue number from commit message. eg: UI_APP:4555 Fixed broken button on IE9 caused by unsupported JS function

Commit frequency: per logical change

Its good to do a new commit per logical change. eg: do a commit once the functional piece is working:

new column 'purchase_amount' added on table
updated the backend to save new purchase_amount column
updated UI to display new column

For bigger update, use a heading and bullet points. The header can be short.

Commit frequency: commit often to have a periodic checkpoint

Imagine you are working on a BIG feature where you modified several files. At some point you are able to make few things working (point X). But when you work on additional changes the things that worked earlier started breaking. Later you are in a position where you don't know how to revert the new changes to get back to the point X where few things were function. If you had committed your changes at point X, it would have made it super easy to revert local changes to that point.

Few good examples:

dialog box UI updated to support multiple callback functions on both Cancel and Save event –> instead of updated dialog box ui
removed the employer contribution period field as we're no longer using it –> instead of removed employer contribution period field
add member import function for the employer user –> instead of added import function

KeyCloak docker-compose import realm file

2021-06-14T19:55:00.000+01:00

Example of docker-compose for keycloak 18 with ability to import a realm file:

It assumes the realm-export.json file is in /PATH_OF_realm-export.json_FILE/

docker-compose.yml:

version: '3'
services:
    keycloak:
        image: 'quay.io/keycloak/keycloak:18.0.2'
        container_name: keycloak
        command: [ 'start-dev --import-realm' ]
        environment:
            - KEYCLOAK_DB=dev-file
            - KEYCLOAK_ADMIN=admin
            - KEYCLOAK_ADMIN_PASSWORD=admin
            - KEYCLOAK_FEATURES=scripts
            - KEYCLOAK_HTTP_PORT=8080
        volumes:
            - /PATH_OF_realm-export.json_FILE/:/opt/keycloak/data/import
        ports:
            - 8082:8080

Kafka - a working docker-compose

2021-05-13T00:59:00.000+01:00

Here's a working docker-compose that runs zookeeper, kafka and kafka-ui in same network.

version: '3.8'
services:

    zookeeper:
        container_name: zookeeper
        image: confluentinc/cp-zookeeper:latest
        hostname: zookeeper
        restart: always
        environment:
            ZOOKEEPER_SERVER_ID: 1
            ZOOKEEPER_CLIENT_PORT: 2181
            ZOOKEEPER_TICK_TIME: 2000
            ZOOKEEPER_INIT_LIMIT: 5
            ZOOKEEPER_SYNC_LIMIT: 2
        ports:
            - 2181:2181

    kafka:
        container_name: kafka
        image: confluentinc/cp-kafka:latest
        depends_on:
            - zookeeper
        restart: always
        environment:
            KAFKA_BROKER_ID: 1
            KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
            KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
            KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092,RMOFF_DOCKER_HACK://kafka:9093
            KAFKA_LISTENERS: PLAINTEXT://:9092,RMOFF_DOCKER_HACK://:9093
            KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,RMOFF_DOCKER_HACK:PLAINTEXT
            KAFKA_INTER_BROKER_LISTENER_NAME: RMOFF_DOCKER_HACK
        ports:
            - 9092:9092

    kouncil:
        container_name: kouncil
        image: consdata/kouncil:latest
        restart: always
        depends_on:
            - kafka
        environment:
            bootstrapServers: kafka:9093
            BOOTSTRAPSERVERS: kafka:9093
            BOOTSTRAP_SERVERS: kafka:9093
        ports:
            - 8888:8080

Spring Boot - shutdown and restart application programmatically

2021-04-18T17:54:00.005+01:00

Today we will be discussing how to shutdown and restart a Spring application programmatically.

1) New Project

First let's create a simple spring boot app with web dependency so that we can setup an endpoint to trigger the shutdown and restart. Let's head over to https://start.spring.io/ and choose web and other dependencies that you need

2) Few words about ApplicationContext and ConfigurableApplicationContext

ApplicationContext is the central interface that represents the Spring IoC container and is responsible for instantiating, configuring, and assembling the beans. ConfigurableApplicationContext is another interface that extends ApplicationContext and provides facilities to configure refresh, startup & shutdown of the application and allows registration of custom listeners to respond to those events.

3) Let's code!

3.1) Simple App

Run the application and store ConfigurableApplicationContext in a static variable appCtx so that we can use it later

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ConfigurableApplicationContext;

@SpringBootApplication
public class App {

    static ConfigurableApplicationContext appCtx;

    public static void main(String[] args) {
        appCtx = SpringApplication.run(App.class, args);
    }

3.2) Shutdown - call ConfigurableApplicationContext.close()

This closes the application context, releasing all resources and locks that the implementation might hold. This includes destroying all cached singleton beans.

static void shutdown() {
    appCtx.close();
}

3.3) Restart

We know how to stop and start the application. To stop, we can simply do:

appCtx.close();

And to start, we can simply call the SpringApplication.run(..)

appCtx = SpringApplication.run(App.class, args);

But the catch here is, appCtx.close() would exit the application and the SpringApplication.run(..) won't be able to run

So, a solution would be to use Daemon Thread to shutdown and start the application. Daemon thread is a type of thread that can run independently in the background(independent of the main thread).

Thread t = new Thread(() -> {
    appCtx.close();
    appCtx = SpringApplication.run(...);
});

t.setDaemon(false);
t.start();

3.4) Passing the original program arguments

We may want to use the original arguments that were passed to run method when we restart the application.

 SpringApplication.run(App.class, args);

We can do that by either storing String[] args in a static variable or use ApplicationArguments bean that Spring Boot creates to store the arguments.

var args = appCtx.getBean(ApplicationArguments.class);      //retrieve
appCtx = SpringApplication.run(App.class, args.getSourceArgs());  //pass

3.5) Web endpoints to trigger the shutdown and restart

@RestController
class Ctrl {

    @GetMapping("/shutdown")
    void shutdown() {
        App.shutdown();
    }

    @GetMapping("/restart")
    void restart() {
        App.restart();
    }
}

4) Complete Example:

package gt.restart;

import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.context.ConfigurableApplicationContext;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
public class App {

    static ConfigurableApplicationContext appCtx;

    public static void main(String[] args) {
        appCtx = SpringApplication.run(App.class, args);
    }

    static void shutdown() {
        if (appCtx.isActive()) {
            appCtx.close();
        }
    }

    static void restart() {
        var args = appCtx.getBean(ApplicationArguments.class);

        Thread thread = new Thread(() -> {
            appCtx.close();
            appCtx = SpringApplication.run(App.class, args.getSourceArgs());
        });

        thread.setDaemon(false);
        thread.start();
    }

}

@RestController
class Ctrl {

    @GetMapping("/shutdown")
    void shutdown() {
        App.shutdown();
    }

    @GetMapping("/restart")
    void restart() {
        App.restart();
    }
}

5) Test

Call the endpoints

GET http://localhost:8080/restart

GET http://localhost:8080/shutdown

Read Request parameter String from URL in Spring/HttpServlet

2021-03-01T17:57:00.001+00:00

Read entire query string(request parameter) in Spring Boot/HttpServlet

In Spring Boot and other Java web frameworks, we capture the request parameters (aka query parameters) and map them to individual variable or a Map<String,String>.

But, if you want to read the entire query parameter in its raw form ( eg: to read name=Ganesh&country=Nepal&ageLt=30&page=1 from request: http://localhost:8080/search?name=Ganesh&country=Nepal&ageLt=30&page=1), you can utilize HttpServletRequest.getQueryString()

Example:

@GetMapping("/test1")
void endpoint1(HttpServletRequest req) {
    var qs = req.getQueryString()  //returns the entire string
    qs.split("&") //split to get the individual parameters
}

Note: Spring Boot automatically resolves the HttpServletRequest object ( its the real holder of request object in Http Servlet environment)

GIT delete merged branches

2021-02-22T18:06:00.002+00:00

How to delete merged branches from local copy:

When you work on a project for a while, there is a good chance that you will have a list of old/already merged branches showing on your local git.

When you run $git branch it will show all the branches since you started working on the project including the ones that are not currently active.

$git branch
    PROJX-1024-add-new-button
    PROJX-1026-add-another-button
    PROJX-1027-titleupdates
    build-fix
    develop
    release
    master

Here's how you can find the merged branches: It will only list a branch if it exists in local but not in remote(deleted from remote after merging).

$git branch --merged
    PROJX-1024-add-new-button
    build-fix
    develop
    release

Here's how you delete the merged branches except develop and release

$git branch --merged | egrep -v "(^\*|develop|release)" | xargs git branch -d

You can add any number of branches to the skip list separated by pipe |

$git branch --merged | egrep -v "(^\*|develop|release|another_branch|yet_another_branch)" | xargs git branch -d

Java view,download,filter email using javax.mail

2020-09-23T02:03:00.003+01:00

Java SDK doesn't come with inbuilt mail API but Java-EE (now called Jakarta EE) provides several utility library like json, servlet, web-service, jms, validation, xml, regexp including email.

In this example I'm going to show how we can connect to email server (eg: gmail) and download/view seen/unseen emails.

Required Dependency :jakarta.mail

Add this dependency with latest version in your pom.xml or manually download/add the jar file to your project's lib.

<dependency>
    <groupId>com.sun.mail</groupId>
    <artifactId>jakarta.mail</artifactId>
</dependency>

The API Usage:

Ideally, the steps would be as following:

- Create Session with host, protocal type etc

- Get message store (Store) for the email protocol. The supported protocols are IMAP, POP, SMTP etc

- Connect to the host using username/password

- Open folder and search for messages

The API Usage with code example:

- Create Session with host, protocol type etc

Properties properties = new Properties();
properties.put("mail.imap.host", host);
properties.put("mail.store.protocol", protocal);
Session emailSession = Session.getDefaultInstance(properties);

- Get message store (Store) for the email protocol. The supported protocols are IMAP, POP, SMTP etc

Store store = emailSession.getStore(protocal);

- Connect to the host using username/password

store.connect(host, user, password);

- Open folder and search for messages

Folder emailFolder = store.getFolder("INBOX");
emailFolder.open(Folder.READ_ONLY);

Search using filters

Flags seen = new Flags(Flags.Flag.SEEN);
FlagTerm unseenFlagTerm = new FlagTerm(seen, false);
Message[] messages = emailFolder.search(unseenFlagTerm);

Complete Example:


import javax.mail.*;
import javax.mail.search.FlagTerm;
import java.util.Properties;

public class MailllllIMAP {

    public static void check(String host, String protocal, String user, String password) {
        try {
            Properties properties = new Properties();
            properties.put("mail.imap.host", host);
            properties.put("mail.store.protocol", protocal);
            Session emailSession = Session.getDefaultInstance(properties);

            Store store = emailSession.getStore(storeType);
            store.connect(host, user, password);
            Folder emailFolder = store.getFolder("INBOX");
            emailFolder.open(Folder.READ_ONLY);

            //unseen email filter
            Flags seen = new Flags(Flags.Flag.SEEN);
            FlagTerm unseenFlagTerm = new FlagTerm(seen, false);
            Message[] messages = emailFolder.search(unseenFlagTerm);

            System.out.println("Total messages: " + messages.length);

            for (Message m : messages) {
                System.out.println(("From: " + m.getFrom()[0]));
                System.out.println(("Subject: " + m.getSubject()));
                System.out.println(("Subject: " + m.getContent()));
                //other fields
            }


            //close or do more stuff
            emailFolder.close(false);
            store.close();

        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args) {

        String host = "pop.gmail.com";
        String protocal = "imaps";
        String username = "XXXX@gmail.com";
        String password = "XXXXXXX";

        check(host, protocal, username, password);

    }

}

What if you get an error like this?

AuthenticationFailedException: [AUTH] Username and password not accepted.

You get this error when trying to gmail. You will need to turn ON the "Allow less secure apps" option on https://www.google.com/settings/security/lesssecureapps

Java HttpClient tutorial with File Upload example

2020-09-23T01:17:00.011+01:00

Java 11 comes with a nice HttpClient API/Implementation so that we no longer need to rely on external libraries like Apache HttpClient execute http requests.

It has the following simple classes(namely HttpClient, HttpRequest, HttpResponse, BodyPublisher, BodyHandler) and they all follow builder pattern to create objects.

Creating HttpClient:

HttpClient client = HttpClient.newBuilder().build();

Creating request:

HttpRequest request = HttpRequest.newBuilder()
        .header("key1", "value1")
        .header("key2", "value2")
        .uri(URI.create("http://localhost:8080/hello"))
        .POST(HttpRequest.BodyPublishers.ofString("Request Body"))
        .build();

Sending request:

client.send(request, HttpResponse.BodyHandlers.APPROPRIATE_HANDLER);

Here, BodyPublisher and BodyHandler can be used to create request body and process returned response respectively. They both support string, byte, file, input stream etc

Upload file using BodyPublishers.ofFile

Normally file upload using a web page are implemented using multi-part(file data with additional properties). But in this example we are going to upload file's byte array in request body and file name in request param.

import java.io.IOException;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.nio.file.Path;

public class HttpTest {
  public static void main(String[] args) throws Exception {
    uploadFile(Path.of("testFile.txt"));
  }

  public static void uploadFile(Path file) throws IOException, InterruptedException {
    HttpClient client = HttpClient.newBuilder().build();

    HttpRequest request = HttpRequest.newBuilder()
      .uri(URI.create("http://localhost:8080/uploadFile?uploader=HttpTestApp&fileName=" 
                  + file.getFileName()))
      .POST(HttpRequest.BodyPublishers.ofFile(file))
      .build();

    client.send(request, HttpResponse.BodyHandlers.ofString());
  }
}

To make the example complete, let's assume we have a following simple Spring Boot app that receives the file byte array as request body:

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.*;

import java.io.*;

@SpringBootApplication
public class FileUploadApp {
    public static void main(String[] args) {
        SpringApplication.run(FileUploadApp.class, args);
    }
}

@Controller
class FileUplCtrl {

  @PostMapping(path = "/uploadFile")
  public void addPhoto(@RequestBody byte[] barr,
              @RequestParam(name = "uploader") String uploader,
              @RequestParam(name = "fileName") String fileName) throws Exception {

   System.out.println("Received file " + fileName + " , uploaded by " + uploader + " Size: " + barr.length);

    //write to disk
    try (OutputStream os = new FileOutputStream(new File("UPL" + fileName))) {
         os.write(barr);
    }

  }
}

Required Dependency on Spring Boot app:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Enjoy coding!

Thymeleaf re-usable pagination component- Spring MVC/Bootstrap

2020-09-14T02:11:00.008+01:00

In this blog, we will discuss how we can create a reusable pagination component using Thymeleaf and Spring MVC/Data.

Goal is to create a pagination UI similar to this:

Controller

Spring resolves the size and page parameter from URL : /users?size=20&page=1 to Pageable object at the Controller methods. We are returning Page<> instead of simple list. Page contains all the information that we need to create the pagination UI as above.

@GetMapping("/articles")
public String userHome(Model model, Pageable pageable) {
    Page<Article> page= articleService.findAllByStatus(Status.PUBLISHED, pageable);
    model.addAttribute("articles", page);
    return "home-page";
}

@GetMapping("/users")
public String userHome(Model model, Pageable pageable) {
    Page<User> page= userRepo.findAllByStatus(Status.ACTIVE, pageable);
    model.addAttribute("users", page);
    return "user-list";
}

Pagination at home-page.html

<th:block th:each="article : ${articles}">
   <!-- display article in a table row or card/box -->
</th:block>

<!--pager at bottom -->
<th:block th:replace="_fragments/_utils :: pagination(${articles})">
</th:block>

Pagination at user-list.html

<th:block th:each="user : ${users}">
   <!-- display user in a table row or card/box -->
</th:block>
<!--pager at bottom -->
<th:block th:replace="_fragments/_utils :: pagination(${users})">
</th:block>

Reusable Fragment Definition at _fragments/_utils.html

Note that the pages are 0 based meaning page=0 equals the first page of data. You can make it to 1 based using the steps described here: https://ganeshtiwaridotcomdotnp.blogspot.com/2020/09/spring-pageable-start-index-with-one.html. You might also need to update the indices below to to handle that.

<th:block th:fragment="pagination(pagedObject)">

    <!-- works with org.springframework.data.domain.Page<pagedObject>, -->

    <div th:if="${pagedObject.getTotalPages() != 1}" class="form-group col-md-11 pagination-centered">
        <ul class="pagination">
            <!-- page number start with 0, totalPages returns actual number of pages -->
            <li th:classappend="${pagedObject.getNumber() == 0} ? disabled" class="page-item">
                <a class="page-link" th:href="@{''(size=${pagedObject.getSize()}, page=0)}">&laquo;</a>
            </li>
            <li th:classappend="${pagedObject.getNumber() == 0} ? disabled" class="page-item">
                <a class="page-link"
                   th:href="@{''(size=${pagedObject.getSize()}, page=${pagedObject.getNumber() -1})}">&larr;</a>
            </li>
            <li th:classappend="${pagedObject.getNumber() == (page  )} ? 'active pointer-disabled'"
                th:each="page : ${#numbers.sequence(0, pagedObject.getTotalPages() -1)}" class="page-item">
                <a class="page-link" th:href="@{''(size=${pagedObject.getSize()}, page=${page})}"
                   th:text="${page + 1}"></a>
            </li>
            <li th:classappend="${pagedObject.getNumber() + 1 == pagedObject.getTotalPages()} ? disabled"
                class="page-item">
                <a class="page-link"
                   th:href="@{''(size=${pagedObject.getSize()}, page=${pagedObject.getNumber() + 1})}">&rarr;</a>
            </li>
            <li th:classappend="${pagedObject.getNumber() + 1 == pagedObject.getTotalPages()} ? disabled"
                class="page-item">
                <a class="page-link"
                   th:href="@{''(size=${pagedObject.getSize()}, page=${pagedObject.getTotalPages()})}">&raquo;</a>
            </li>
        </ul>

        <p class="text-muted small">
            Showing page <span th:text="${pagedObject.getNumber() +1}"></span> of <span
            th:text="${pagedObject.getTotalPages()}"></span>.
            Total: <span th:text="${pagedObject.getTotalElements()}"></span>.

        </p>
    </div>


    <div th:if="${pagedObject.getTotalElements() ==0}">
        <div class="alert alert-warning" role="alert">
            <span>No items available.</span>
        </div>
    </div>


</th:block>

Reference: https://github.com/gtiwari333/spring-boot-web-application-seed/blob/master/main-app/src/main/resources/templates/_fragments/_utils.html

Thymeleaf pass parameter to fragment

2020-09-14T01:51:00.004+01:00

Making reusable fragment/UI Components in Thymeleaf

Thymeleaf supports creation of 'function like' mechanism and pass parameters to make the UI components reusable.

In this example we are going to create a reusable alert component using thymeleaf:

The fragment definition is similar to how a function/method is defined:

File: _fragments/_utils.html

<div th:fragment="alertBox(message,type)">
    //do stuff with message and type
</div>

Let's call with some parameters in another file:

<div th:replace="_fragments/_utils::alertBox ('A message','success')">
</div>

The parameter order is not important if you do like this:

<div th:replace="_fragments/_utils::alertBox (type = 'success', message='A message' )">
</div>

A complete example:

<div th:fragment="alertBox (message,type)">
    <div
        th:classappend="|
            ${type == 'success' ? 'alert-success': ''}
            ${type == 'info' ? 'alert-info': ''}
            ${type == 'danger' ? 'alert-danger': ''} |"
        class="alert alert-dismissible">
        <a href="#" class="close" data-dismiss="alert" aria-label="close">&times;</a>
        <span th:text="${message}"></span>
    </div>
</div>

Calling it:

<div th:replace="_fragments/_utils :: alertBox ('Hello this is a success!','success')">
</div>

<div th:replace="_fragments/_utils :: alertBox ('Danger! danger! .......','danger')">
</div>


<div th:replace="_fragments/_utils :: alertBox ( type = 'success', message='Success message' )">
</div>

Output:

Spring pageable - start index with one

2020-09-13T20:05:00.004+01:00

By default Spring uses 0 indexed page meaning a page number of 0 in the request equals the first page.

You can customize this to start from 1 in following by creating a bean of PageableHandlerMethodArgumentResolverCustomizer and setting the setOneIndexedParameters to true.

You can read more about the method argument resolver and other customizations to pagable in my earlier blog post: https://ganeshtiwaridotcomdotnp.blogspot.com/2020/09/spring-data-pagination-set-max-page.html

Configures whether to expose and assume 1-based page number indexes in the request parameters. When its true, a page number of 1 in the request will be considered the first page.

@Bean
public PageableHandlerMethodArgumentResolverCustomizer paginationCustomizer() {
  return pageableResolver -> {
     pageableResolver.setOneIndexedParameters(true); //default is false, starts with 0
  };
}

Now you can have your pagination url to start with page=1 eg: /users?size=20&page=1.