In plain words
Java programs can call language models through different client frameworks. Those clients may react differently when a provider is slow, sends an error, or cuts off a stream.
The paper introduces a shared set of six reliability rules and a Java library that applies them where requests and responses pass over HTTP. In scripted failure tests, the three guarded client paths behaved alike and met all six rules in nearly all applicable checks. A slow first chunk still exposed a timeout trade-off.
The research
When a model provider fails, Java client frameworks may handle retries, timeouts, and broken streams differently. Can one shared layer make those behaviors follow the same reliability rules across frameworks and a plain Java client?
The paper tests this question with a contract that spells out what handling a call should guarantee.
A six-clause contract and shared Java HTTP guard apply the same provider-failure rules beneath three Java client paths.
A provider failure can be handled differently by different Java clients. Can one shared layer make their behavior follow the same reliability rules? The paper answers with a six-clause contract and a Java library placed at the HTTP boundary beneath two frameworks or a plain Java client.
In scripted tests, the guarded Spring AI, LangChain4j, and plain Java clients each met all six clauses in nearly all applicable checks and matched in attempts and recorded failure kinds.
This supports consistent handling across these tested paths; a slow first stream event still exposed a timeout trade-off.
The evidence comes from scripted OpenAI-compatible failures and success-only calls to one local server. It does not show how the guard handles real provider failures under load, other provider protocols, or later framework versions. The study also tests one timeout policy.
Analysis
Deep
- Original paper authors
- Oleksandr Klymenko
- Submitted to arXiv
- License
- arXiv non-exclusive