Claude
b81af72bc3
Companion code for "Spring Batch on Boot 4.1: Jobs, Steps, Chunk Processing and Restartability". A productImportJob configured three ways by profile against a poisoned CSV row, run as real java -jar processes (not just JUnit) so the restart story is genuine: a chunk fails and rolls back, the process exits, a brand-new JVM against the same file-based H2 database resumes at the exact next unread row (READ_COUNT 20, not 60) and completes. Findings the build pins: - StepBuilder.chunk(int, PlatformTransactionManager) still compiles in Batch 6.0.5 but returns the legacy SimpleStepBuilder; chunk(int) returns the new ChunkOrientedStepBuilder, and only the latter is used here. - Two different ExecutionContext classes now exist in two different packages (infrastructure.item vs core.repository.persistence) with different shapes. - spring-boot-starter-batch alone gives a resourceless JobRepository that forgets every JobInstance the moment the JVM exits; spring-boot-starter- batch-jdbc is what makes the restart demo possible at all, demonstrated by excluding BatchJdbcAutoConfiguration and watching a "restart" collide with the previous run's own data instead of resuming it. - A migration-guide summary claiming CommandLineJobRunner was removed in 6.0 is wrong -- javap against the real jar shows @Deprecated(forRemoval=true), not removed. - RepeatStatus moved from core.repeat to infrastructure.repeat, caught by the compiler rather than by reading docs. 11 documentation chapters, 10 captured transcripts (unit tests, javap output, and real two-JVM scenario runs), all regenerated by scripts/run-all.sh. Fixed after push: three dead docs.spring.io links in the doc chapters (readersAndWriters/* and chunk-oriented-processing/*.html paths moved when Spring Batch 6 reorganized its reference docs; corrected to the current readers-and-writers/*, processor.html and chunk-oriented-processing.html paths, verified 200 via curl before committing). Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_019DXsJ1zpikbA1MQJN6RqFA
58 lines
3.1 KiB
Markdown
58 lines
3.1 KiB
Markdown
# 9. Corrections found while writing this
|
|
|
|
[← Previous](08-skip-vs-restart.md) | [README](../README.md) | [Next: Resourceless vs. JDBC-backed →](10-resourceless-vs-jdbc.md)
|
|
|
|
Per the verification discipline this repository follows, here is what was wrong in an earlier
|
|
draft, and how it was caught — recorded honestly rather than silently fixed, because the
|
|
mistake is often as informative as the correct answer.
|
|
|
|
## "CommandLineJobRunner was removed in 6.0" — wrong, it is deprecated
|
|
|
|
A community-written Spring Batch 6.0 migration guide describes `CommandLineJobRunner` as removed
|
|
outright, in a list alongside classes that genuinely were deleted
|
|
(`ChunkListenerSupport`, `JobExecutionListenerSupport`, and others). An early draft of this
|
|
article repeated that claim. Checking the actual `spring-batch-core-6.0.5.jar` shows it is wrong:
|
|
|
|
```console
|
|
$ javap -verbose -cp spring-batch-core-6.0.5.jar org.springframework.batch.core.launch.support.CommandLineJobRunner | grep -A3 "^public class\|Deprecated"
|
|
public class org.springframework.batch.core.launch.support.CommandLineJobRunner
|
|
...
|
|
Deprecated: true
|
|
RuntimeVisibleAnnotations:
|
|
0: #505(#506=s#507,#508=Z#509)
|
|
java.lang.Deprecated(
|
|
since="6.0"
|
|
forRemoval=true
|
|
)
|
|
```
|
|
|
|
Full transcript: [`docs/output/09-commandlinejobrunner-deprecated-not-removed.txt`](output/09-commandlinejobrunner-deprecated-not-removed.txt).
|
|
The class is present, loadable, and functional in 6.0.5 — it carries
|
|
`@Deprecated(since = "6.0", forRemoval = true)`, which means "stop using this, it will be
|
|
deleted in a future release," not "this is already gone." `CommandLineJobOperator` is the
|
|
replacement, and it does exist alongside it in the same package.
|
|
|
|
This is the article's own self-correction pass working as intended: a claim sourced from a
|
|
third-party summary of a migration guide, not from a primary artifact, was treated as unverified
|
|
until checked. The general rule this project follows (see the parent repository's process notes)
|
|
is that a migration guide's own prose is not itself a primary source for "removed vs.
|
|
deprecated" — the jar is.
|
|
|
|
## `RepeatStatus` package move, caught by the compiler rather than by reading docs
|
|
|
|
Writing [`BatchConfig.reportTasklet`](../src/main/java/com/ankurm/batch/config/BatchConfig.java),
|
|
the first draft imported `org.springframework.batch.core.repeat.RepeatStatus` — the
|
|
Spring Batch 5.x location, from memory and from older examples. `mvn -B -o compile` reported:
|
|
|
|
```
|
|
[ERROR] .../BatchConfig.java:[93,57] package org.springframework.batch.core.repeat does not exist
|
|
```
|
|
|
|
The fix was `org.springframework.batch.infrastructure.repeat.RepeatStatus`, matching the general
|
|
package reorganization covered in [chapter 2](02-anatomy-of-a-job.md). No migration guide was
|
|
consulted for this one; the compiler error was sufficient, which is the point — letting
|
|
`javac` tell you where an API moved is faster and more reliable than trying to remember or look
|
|
up a package reorganization table.
|
|
|
|
[Next: Resourceless vs. JDBC-backed →](10-resourceless-vs-jdbc.md)
|