[lmi v29] Upgrade DJL and DJL-Serving to 0.38.0

[shiehbeth]

Description

Upgrade DJL and DJL-Serving from 0.36.0 to 0.38.0 for the LMI 29.0.0 release, following the
shape of #2981 ("[lmi v18] Upgrade DJL and DJL-Serving to 0.36.0").

This is the first DJL bump of the LMI line since v18 — LMI v19 through v28 all rode DJL 0.36.0,
so gradle/libs.versions.toml has been unchanged for ten releases.

This PR originally targeted 0.37.0 and was retargeted to 0.38.0 in e1ed465d at
@xyang16's request, so LMI 29 ships the current DJL release. v29 therefore skips 0.37.0
entirely, and a customer moving lmi28 → lmi29 inherits both releases' behavior changes.
The head branch is still named upgrade-djl-0.37.0: GitHub cannot rename a PR's head branch
without closing and reopening the PR, which would discard this review thread and the CI history,
so the stale branch name is deliberate.

File	Change
gradle/libs.versions.toml	djl and serving → 0.38.0
.github/workflows/optimization_integration.yml	TEST_SERVING_VERSION fallback → 0.38.0
serving/src/test/java/ai/djl/serving/WorkflowTest.java	opt in to dynamic Java compilation — see below
.github/workflows/continuous.yml	set DJL_COMPILE_JAVA=true for the Gradle step — see below

The first two are the only places in the repo that carry the version literal (grep -rn '0\.36\.0'
over workflows, *.gradle*, *.toml, *.properties returns exactly those three lines).

WorkflowTest: opting in to dynamic Java compilation

The third file is not a version literal — it is a required adaptation to a DJL behavior change
introduced in 0.37.0 and carried into 0.38.0, and it is why this PR is not a pure two-file bump.

deepjavalibrary/djl#3875 makes compilation of bundled .java sources opt-in, gated on
DJL_COMPILE_JAVA / -Dai.djl.compile_java. ClassLoaderUtils.compileJavaClass now returns early
unless compilation is explicitly enabled.

WorkflowTest.testFunctions loads serving/src/test/resources/workflows/functions.json, which
declares the custom function oid backed by
workflows/libs/classes/.../OtherIdentityWF.java — a source file compiled at load time by
WorkflowDefinition. With compilation off by default the class is never produced,
findImplementation returns null, and the test fails with
BadWorkflowException: Could not load function oid. All three build (*) jobs failed on this
deterministically before this commit.

The fix enables the system property for the duration of that one test, mirroring what DJL applied to
its own CustomTranslatorTest in the same commit.

The test still runs — it is not skipped. The SkipException guard is
if (envOptIn != null && !Boolean.parseBoolean(envOptIn)), so it fires only when DJL_COMPILE_JAVA
is both set and parses false. On an unset environment — which is every job in this repo's CI —
neither condition holds, the property is set, and the test executes. The guard exists because the
environment variable takes precedence over the system property in DJL, so an environment that
explicitly pins compilation off would otherwise see this test fail for a reason unrelated to the
code under test. Evidence, from the run on 7fcf2696: WorkflowTest > testFunctions PASSED on all
three platforms; and locally against 0.38.0, the TestNG report records tests="6" skipped="0" failures="0" errors="0" with testFunctions taking 0.795s.

The fourth file adopts @xyang16's review suggestion to set DJL_COMPILE_JAVA=true for
continuous.yml's Gradle step, making the opt-in explicit at the CI level rather than relying solely
on the in-test system property. It is CI-only and does not change the shipped container, which keeps
DJL 0.38.0's compilation-off default. Self-contained on the semantics too: WorkflowTest is the only
consumer of that variable in this repo, no test asserts the compilation-off default, and
continuous.yml is the only workflow that runs the serving test suite (client-test.yml's
./gradlew build runs in tests/java-client).

One adjustment to the suggested form, in 473e8a93. It was first applied literally, as a command
prefix (run: DJL_COMPILE_JAVA=true ./gradlew ...), which broke build (windows-latest): this
workflow's matrix is [ubuntu-latest, windows-latest, macos-latest] and it sets no
defaults.run.shell, so Windows runs the step under PowerShell, where NAME=value cmd is not a valid
assignment prefix. The step failed in 27s with every preceding step green, ubuntu and macos
unaffected. It is now a step-level env: block, which sets the variable identically on all three
runners and leaves the run: line byte-for-byte as it was:

      - name: Build with Gradle
        env:
          DJL_COMPILE_JAVA: "true"
        run: ./gradlew --refresh-dependencies build :jacoco:testCodeCoverageReport --stacktrace

The WorkflowTest change is deliberately test-only. It does not change the serving default, so
the arbitrary code execution path #3875 closed stays closed. Scope is repo-complete: there is exactly
one bundled .java in the repo (OtherIdentityWF.java) and exactly one compileJavaClass call site
in main code (WorkflowDefinition), so no other test or product path is affected.

Note for downstream consumers: users who ship custom translators or workflow functions as bundled
.java now need DJL_COMPILE_JAVA=true. LMI's Python (engine=Python) path is unaffected.

Why the other files from #2981 are not here

#2981 also touched serving/docs/lmcache_performance.md, tests/integration/llm/prepare.py,
tests/integration/tests.py, and tests/integration/lmcache_configs/djl_long_doc_qa_clean.py.
Those were incidental lmi18 content bundled into the same PR — a new LMCache doc plus yapf
reformatting — not part of the version upgrade, so they have no 0.38.0 analogue.

serving/docs/lmi/release_notes.md is deliberately deferred. That file currently tops out at
LMI V20; v21–v28 never added sections, so it is already ten releases stale, and the V29 entry
depends on benchmark numbers that have not been produced yet. Adding release notes here would
either fabricate figures or open a docs-backfill discussion inside a version-bump PR. Happy to
fold it in if reviewers would rather keep #2981's exact file set.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

Checklist:

• Please add the link of Integration Tests Executor run with related tests.
• Have you manually built the docker image and verify the change?
• Have you run related tests? Check how to set up the test environment here
• Have you added tests that prove your fix is effective or that this feature works?
• Has code been commented, particularly in hard-to-understand areas?
• Have you made corresponding changes to the documentation?

Feature/Issue validation/testing

Verified locally against DJL 0.38.0 (Corretto 17, matching this repo's CI distribution and
java-version), running the same invocation the updated continuous.yml uses
(DJL_COMPILE_JAVA=true ./gradlew --refresh-dependencies ...):

• --refresh-dependencies re-resolved every ai.djl* coordinate to 0.38.0-SNAPSHOT
  (:serving:dependencies --configuration runtimeClasspath), so this is a genuine resolution against
  the new line and not a cached 0.37.0.
• :serving:compileJava and :serving:compileTestJava succeeded — no API break in a class
  djl-serving consumes.
• WorkflowTest: 6 tests, 0 failures, 0 errors, 0 skipped, including testFunctions.

Upstream artifact availability, confirmed directly rather than assumed. Both the release and the
snapshot line are needed, because release-mode nightly builds ${DJL_VERSION} while nightly-mode
builds ${DJL_VERSION}-SNAPSHOT:

Artifact	Result
ai.djl:bom:0.38.0 (Maven Central)	200
ai.djl:bom:0.38.0-SNAPSHOT (central.sonatype.com/repository/maven-snapshots)	200 — buildNumber 1, 20260910.191548
ai.djl:api:0.38.0-SNAPSHOT (same)	200
ai.djl.serving:serving:0.38.0	404 as expected — this repo produces it

The BOM snapshot matters specifically because tests/java-client/build.gradle.kts resolves
platform("ai.djl:bom:${libs.versions.djl.get()}-SNAPSHOT"), so that CI check would fail fast if
0.38.0-SNAPSHOT were not published. It is worth recording why that line is now available: djl master
carried 0.38.0 for only ~8h, so nightly_publish.yml's 0 10 * * * cron never fell inside that
window and the snapshot was initially absent. @xyang16 dispatched the publish workflow by hand, which
is what makes this retarget possible.

Note that oss.sonatype.org no longer serves DJL snapshots — 200 only on
central.sonatype.com/repository/maven-snapshots.

0.39.0 is not a viable target today, for the record: 0.39.0-SNAPSHOT exists but the release
coordinate ai.djl:bom:0.39.0 is 404, and a release-mode nightly builds the release coordinate.

Compilation against the DJL 0.38.0 API surface is what this PR's CI validates — if 0.37.0 or 0.38.0
introduced a breaking change in a class djl-serving consumes, the Java build jobs surface it here
rather than during the release nightly. That is worth stating plainly: because master pins
serving = "0.36.0" and resolves ai.djl:bom:0.36.0-SNAPSHOT, whose last publish predates #3875,
master CI could not have caught this. The version-bump PR is where accumulated DJL changes first
become visible to this repo — and since v29 skips 0.37.0, this PR is the only integration test
covering two DJL releases at once. The green checks earned on 7fcf2696 were against 0.37.0 and
do not carry over; the build (*) jobs are re-running on 473e8a93.

Relationship to #3075

Independent of, and mergeable in either order with, #3075 (the vLLM 0.28.0 wheel bump for LMI
29.0.0). Both are required for the LMI 29.0.0 container: #3075 moves the Python/vLLM/torch layer,
this PR moves the Java/DJL layer. #3075 is unaffected by this retarget — it is Python/wheel only.
Note that until this PR merges, a nightly build produces images tagged 0.36.0-*, since the docker
tag is derived from serving in libs.versions.toml.

[xyang16]

This change will make this test skipped.

Consider update https://github.com/deepjavalibrary/djl-serving/blob/v0.36.0/.github/workflows/continuous.yml#L48 to:

        run: DJL_COMPILE_JAVA=true ./gradlew --refresh-dependencies build :jacoco:testCodeCoverageReport --stacktrace

[xyang16]

        boolean envOptIn = Boolean.parseBoolean(Utils.getenv("DJL_COMPILE_JAVA", "false"));
        boolean propOptIn = Boolean.parseBoolean(System.getProperty("ai.djl.compile_java", "false"));
        if (!envOptIn && !propOptIn) {
            throw new SkipException("Java compilation is disabled");
        }