Upgrade to JDK 17 (and Payara 6 / Jakarta EE) — unlocks official MCP SDK + language cleanup

[iTerminate]

Summary

Upgrade the runtime from JDK 11 to JDK 17. This almost certainly requires moving from Payara 5.2022.5 (Java EE 8, javax.*) to Payara 6 (Jakarta EE 9+, jakarta.*), since Payara 5 is pinned to JDK 11/8.

Current state

• support/bin/install_java.sh pins JAVA_VERSION=11+28
• support/bin/install_glassfish.sh pins PAYARA_VERSION=5.2022.5
• src/java/LogrPortal/nbproject/project.properties — javac.source/javac.target were bumped from 1.8 to 11 for the MCP endpoint work (#TBD), confirmed to build clean at 11. They are not yet at 17.
• Payara 5's officially supported JDK ceiling was not verified during that work (docs.payara.fish was unreachable at the time) — confirm this before scoping the upgrade, since it determines whether Payara 6 is strictly required or whether some intermediate step is possible.

Why this is a real migration, not a version bump

Payara 6 speaks Jakarta EE (jakarta.* package namespace), not Java EE 8 (javax.*). Every javax.* import in the application would need to move to jakarta.*:

• JSF 2.3 → Jakarta Faces
• EJB 3.2 → Jakarta Enterprise Beans
• JPA 2.2 (EclipseLink) → Jakarta Persistence
• JAX-RS 2.1 (Jersey) → Jakarta RESTful Web Services
• PrimeFaces 11 / PrimeFaces Extensions, OmniFaces 3 — need Jakarta-compatible releases
• Any other lib/ jar with javax.* in its own API surface

This is a full-codebase namespace migration plus a compatibility check on every third-party UI/JSF library currently pinned in lib/, not something to fold into an unrelated feature PR.

Potential cleanup this unlocks

1. Adopt the official MCP Java SDK for /api/mcp

The /api/mcp endpoint (added in the MCP work, see src/java/LogrPortal/src/java/gov/anl/aps/logr/rest/mcp/) hand-implements the JSON-RPC/MCP wire protocol because io.modelcontextprotocol.sdk:mcp-core was blocked by four independent issues, all resolved by this upgrade:

1. Java 17 bytecode — mcp-core-2.0.1.jar classes are major version 61; this runtime is JDK 11.
2. jakarta.servlet-api 6.1.0 — the SDK requires the Jakarta namespace; this app is Java EE 8.
3. Transitive dependency conflicts against this project's flat, manually-resolved lib/ (slf4j 2.0.16 vs. the project's 1.7.26, Jackson 2.21 vs. 2.11.2, plus reactor-core/reactive-streams).
4. Protocol revision lag — at time of writing the SDK only shipped 2024-11-05 through 2025-11-25, not the 2026-07-28 revision this endpoint implements.

Once on JDK 17 + Payara 6, re-check whether the SDK has caught up to whatever protocol revision is current, and if so, replace:

• rest/mcp/protocol/ (JsonRpcRequest, JsonRpcResponse, JsonRpcError, McpProtocolException)
• rest/mcp/schema/JsonSchemaBuilder
• The header/body mirror validation and dispatch logic in rest/mcp/McpRoute

with the SDK's McpSchema types, transport, ToolInputValidator/JsonSchemaValidator, and session lifecycle — keeping only the 8 tool implementations and the BELY-specific facade wiring (McpToolContext).

2. Language-level cleanup from JDK 11 → 17

JDK 11 (already in use) only bought var, List.of/Map.of, String.isBlank, Optional.isEmpty. JDK 17 adds:

• Records — could replace small immutable DTOs, e.g. in the MCP protocol layer and rest/entities/.
• Text blocks — would clean up the multi-line SQL/JSON/instruction strings currently built with string concatenation (e.g. McpConstants.INSTRUCTIONS).
• Pattern matching for instanceof — several instanceof X; X y = (X) obj; pairs across the REST routes and MCP tools could collapse (e.g. rest/mcp/tools/impl/BelyGetLogDocumentTool, BelyListLogEntriesTool, BelyGetLogEntryTool all do item instanceof ItemDomainLogbook then cast).
• Sealed classes — worth considering for exception hierarchies like common/exceptions/CdbException and its subtypes, or the McpTool implementations.

Suggested scoping for the eventual work

1. Confirm Payara 5's actual supported-JDK ceiling (docs.payara.fish) and whether Payara 6 is the only path to JDK 17.
2. Spike the javax.* → jakarta.* migration in a branch; identify every third-party lib/ jar that needs a Jakarta-compatible replacement (PrimeFaces, PrimeFaces Extensions, OmniFaces are the highest-risk ones).
3. Once the app builds and deploys clean on Payara 6 / JDK 17, bump javac.source/javac.target to 17.
4. Only then take on the MCP SDK swap and any records/text-block/pattern-matching cleanup as separate, smaller follow-up PRs — don't bundle language-level cleanup into the migration PR itself.