Private corporate batches, live online cohorts and 1-on-1 mentoring in on-the-fly JVM bytecode coverage through the Java agent — instruction, branch and line counters wired into Maven, Gradle, Ant and CI — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches JaCoCo from the mechanism outward: how the Java agent and ASM insert probes at class load, why instruction and branch counters disagree with line coverage, what a class id mismatch is actually telling you, and how execution data from unit, integration and container runs is merged into one honest report. Sessions cover the integration surface in full — Maven lifecycle binding, Gradle verification tasks, Ant tasks, the command line interface and the TCP agent for long-running servers — and the coverage gate design that blocks bad changes without producing tests written to satisfy a percentage. Twenty years across DevOps, SRE and Security and 10,000+ engineers trained inform the build and pipeline decisions.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For JaCoCo that means a trainer who has run it in production — on-the-fly JVM bytecode coverage through the Java agent — instruction, branch and line counters wired into Maven, Gradle, Ant and CI — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private JaCoCo batchJaCoCo is the code coverage library for the JVM, developed as part of the EclEmma project. It measures which bytecode was executed while a program ran, and it does so by instrumenting classes on the fly: a Java agent registers a class-file transformer, and as each class is loaded the ASM library inserts probes into it in memory. Nothing on disk is modified, no separate instrumentation build step exists, and the application under measurement is the same artefact the tests would have run against anyway. That single design decision is what separates JaCoCo from the older generation of Java coverage tools.
JaCoCo counts more than lines. It maintains five counters — instructions, branches, lines, methods and classes — plus cyclomatic complexity, and it derives them from bytecode rather than from source, which is why line coverage requires classes compiled with debug information and why a single source line can be partially covered. Execution data is written to a binary `.exec` file, keyed by a class id: a CRC64 hash of the class file itself. Reporting joins that execution data back to the class files and the sources, and if the classes have been recompiled since the run, JaCoCo refuses to guess and reports a class id mismatch instead of silently producing a wrong number.
Around that core sit the integrations most teams actually touch. The Maven plugin binds `prepare-agent`, `report`, `report-aggregate` and `check` into the build lifecycle; the Gradle plugin does the same through the JacocoReport and JacocoCoverageVerification tasks; Ant tasks and a command line interface cover everything else, and a Java API exists for tools that embed it. The agent can also expose execution data over TCP so a long-running server can be dumped without stopping it, and an offline instrumentation mode exists for the runtimes where a Java agent is not an option at all.
Coverage stopped being a report someone reads and became a gate that blocks a merge. Pull request decoration in SonarQube, GitLab and GitHub all consume a coverage number per change, and on the JVM that number is almost always produced by JaCoCo — it is the de facto standard, the format SonarQube expects, and the one that build tools ship support for out of the box.
That makes it worth understanding properly rather than copying from a sample POM. The failure modes are specific and common: a plugin configured so the agent argument never reaches the test JVM, forked or containerised test executions that write execution data somewhere the report never looks, multi-module projects where each module reports on itself and nobody aggregates, integration tests whose coverage is discarded because only the surefire run was measured, and generated code that drags a perfectly healthy number down until the right filters are applied.
The wider reason is the coverage gate itself. Setting a blanket eighty percent target on a legacy codebase reliably produces tests written to touch code rather than to assert anything. Configuring `check` rules on new code, on the counters that matter, at the scope where the team can act, is a different and far more useful skill — and it is one that requires knowing what JaCoCo is measuring rather than just what number it printed.
The measurement before the tooling. What executing a line proves and what it does not, why coverage is a diagnostic rather than a target, and where the number is actively misleading. Then JaCoCo's counter model, which is richer than most teams realise, and the honest comparison against the other JVM coverage tools.
Topics: Statement, line, branch and path coverage as concepts · JaCoCo's five counters: instructions, branches, lines, methods, classes · Cyclomatic complexity and its counter · Why coverage of a line does not mean the line is tested · Coverage versus mutation testing as evidence · JaCoCo, Cobertura and the JVM coverage landscape · Licensing and the EclEmma project
How JaCoCo actually works. The `-javaagent` mechanism, the class-file transformer, ASM inserting probes into bytecode at load time, and the runtime data structure that records them. Then every agent option that matters, and what happens when the agent argument silently fails to reach the JVM that runs the tests.
Topics: The Java agent mechanism and class-file transformers · ASM and probe insertion at class load · The jacocoagent.jar options: destfile, append, includes, excludes · inclbootstrapclasses, inclnolocationclasses and classloader edge cases · Why classes must be compiled with debug information for line coverage · output modes: file, tcpserver, tcpclient and none · Agent overhead and its effect on test runtime · Diagnosing an agent that never attached
The file in the middle of everything. The binary exec format, why every class is keyed by a CRC64 class id rather than a name, what a class id mismatch means, and how to merge execution data from separate runs — unit, integration, and a server dumped over TCP — into one report without double counting or silently dropping data.
Topics: The .exec execution data format · Class ids: CRC64 of the class file and why they exist · Execution data for class X does not match — cause and fix · append mode and accumulating data across runs · Merging exec files from unit and integration phases · Dumping data from a running JVM over TCP · Session information and per-session data · Reproducible builds and stable class ids
The most common integration, done correctly rather than copied. Lifecycle binding of prepare-agent, the argLine property and how surefire consumes it, the failsafe equivalent for integration tests, report generation and the file layout it expects. Then the multi-module problem that most builds get wrong.
Topics: The jacoco-maven-plugin and its goals · prepare-agent, argLine and surefire interaction · prepare-agent-integration and report-integration with failsafe · Overriding argLine safely when the build already sets it · report goal: HTML, XML and CSV output · merge goal across execution data files · report-aggregate in a multi-module reactor · Skipping, excluding and profile-based coverage
The other two build systems, both of which expose JaCoCo differently. The Gradle jacoco plugin, its extension on Test tasks, JacocoReport and JacocoCoverageVerification; then the Ant task library — coverage, report, merge, dump and agent — including the offline usage example that the Ant integration is often chosen for.
Topics: The Gradle jacoco plugin and the jacoco extension on Test tasks · JacocoReport: source sets, class directories and report formats · JacocoCoverageVerification and violation rules · Gradle multi-project aggregation · Ant task library and taskdef setup · The coverage task wrapping a java or junit call · Ant report, merge, dump and instrument tasks · Ant offline instrumentation usage example
What to do when a Java agent is not available. Offline instrumentation rewrites the classes ahead of time and requires jacocoagent on the runtime classpath instead; the trade-offs are real and the failure modes are different. The module covers when this is genuinely necessary and how to keep instrumented classes out of a release artefact.
Topics: When on-the-fly instrumentation is not possible · The instrument goal, task and command · Runtime classpath requirements for offline mode · jacoco.agent runtime artefact and the classifier that matters · Keeping instrumented classes out of released artefacts · Android, application servers and custom classloaders · Offline example with Maven and with Ant · Choosing between offline and on-the-fly deliberately
Making the report tell the truth. HTML, XML and CSV output and what each is for, source linking, the built-in filters that exclude synthetic and generated code, and the exclusion patterns teams need for generated sources, DTOs and framework glue. Then reading a partially covered line and acting on it.
Topics: HTML, XML and CSV report formats and their consumers · Source directories and source linking in the HTML report · Built-in filters: synthetic methods, bridge methods, try-with-resources · Lombok, records, enums and generated code filtering · excludes patterns in the agent versus in the report · Reading a partially covered branch in the HTML view · Class, package and bundle level roll-up · Trend data and comparing reports over time
Turning a number into a control. The check goal and verification rules — element, counter, value and limits — and the design question behind them: a blanket target on a legacy codebase produces assertion-free tests, whereas a rule on new code changes behaviour without a rewrite programme. Covers ratcheting and exemption governance.
Topics: The check goal and JacocoCoverageVerification rules · Rule elements: BUNDLE, PACKAGE, CLASS, METHOD · Counters and limit values: COVEREDRATIO, MISSEDCOUNT · Why a blanket percentage target backfires · New-code gates versus whole-codebase targets · Ratcheting a legacy codebase upward safely · Exclusions, exemptions and who approves them · Failing a build versus reporting a warning
The last mile. Publishing coverage in Jenkins and other CI systems, feeding the XML report into SonarQube so coverage appears on the pull request, and the jacococli command line for the cases the build plugins do not cover — dump, merge, report, instrument and class inspection. Ends with the Java API for tools that embed JaCoCo.
Topics: Jenkins coverage publishing and trend graphs · sonar.coverage.jacoco.xmlReportPaths and SonarQube integration · Pull request decoration and new-code coverage · GitLab and GitHub coverage reporting from the XML · jacococli: dump, merge, report, instrument · jacococli classinfo and execinfo for diagnosis · Coverage from containerised and remote test runs · The JaCoCo Java API for embedding and custom tooling
We rebuild the agenda around the tools you actually run.
Request a custom agendaRun a test suite with -javaagent set manually, inspect the exec file with jacococli, and account for every class that appears and every one that does not.
Measure surefire and failsafe runs separately, merge the execution data, and produce a single report that neither run could have produced alone.
Take a five-module Maven build where each module reports on itself, and produce one aggregate report that a reviewer can actually read.
Instrument a project offline, run it with the runtime artefact on the classpath, produce a report, and prove the instrumented classes never reach the release JAR.
Configure check rules on a legacy codebase so a regression fails the build while the existing debt does not, then raise the floor over successive builds.
Measure, merge and gate coverage in CI, publish the XML into SonarQube, and surface new-code coverage on the pull request where reviewers see it.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
I took Terraform training with the tutor named Mithilesh. I requested to tailor the course curriculum for my needs. He did an excellent job of showing me how to write the Terraform script per the instructions provided.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.