You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Closing as this is not needed currently and should be generally OK - I've improved the cross build here to support Spark 4 and Java 17 for some parts of the project; the reader should be compatible with Java 11: #486
Further reasoning:
reader only has a Scala cross-build axis (2.12/2.13 via addScalaCrossBuild) - every row compiles with a single fixed Java 8 target. There's no Java-version axis at all for reader (or model) in this build — unlike agent's Spark3/Spark4 split, which exists specifically because Spark 4 itself requires JDK 17 to even compile against.
The reader's dependencies (sttp-client3, cats-effect, circe) are all plain Java-8-compatible libraries — nothing in there needs Java 9+ APIs.
So there's no forcing function requiring a Java 11 variant, the way Spark 4 forced one for the agent. Java 8 bytecode already runs fine on any newer JVM (11, 17, 21...), so the current single Java 8 target already gives Reader maximum compatibility for free — a separate Java 11 build would only be worth adding if we specifically wanted Reader to use a Java 9-11+ only API.
Re HTTP concern from the ticket's description: every Reader/PartitioningReader/FlowReader etc takes backend: SttpBackend[F, Any] as an implicit parameter supplied by the caller. Reader only depends on sttp's core + circe modules,, not any concrete backend module.
So the choice of transport (e.g HttpURLConnectionBackend, OkHttp, Akka) is entirely up to whoever uses Reader, hopefully.
Activity
lsulak commentedon Sep 24, 2026
Closing as this is not needed currently and should be generally OK - I've improved the cross build here to support Spark 4 and Java 17 for some parts of the project; the
readershould be compatible with Java 11: #486Further reasoning:
reader only has a Scala cross-build axis (2.12/2.13 via addScalaCrossBuild) - every row compiles with a single fixed Java 8 target. There's no Java-version axis at all for reader (or model) in this build — unlike agent's Spark3/Spark4 split, which exists specifically because Spark 4 itself requires JDK 17 to even compile against.
The reader's dependencies (sttp-client3, cats-effect, circe) are all plain Java-8-compatible libraries — nothing in there needs Java 9+ APIs.
So there's no forcing function requiring a Java 11 variant, the way Spark 4 forced one for the agent. Java 8 bytecode already runs fine on any newer JVM (11, 17, 21...), so the current single Java 8 target already gives Reader maximum compatibility for free — a separate Java 11 build would only be worth adding if we specifically wanted Reader to use a Java 9-11+ only API.
Re HTTP concern from the ticket's description: every Reader/PartitioningReader/FlowReader etc takes backend: SttpBackend[F, Any] as an implicit parameter supplied by the caller. Reader only depends on sttp's core + circe modules,, not any concrete backend module.
So the choice of transport (e.g HttpURLConnectionBackend, OkHttp, Akka) is entirely up to whoever uses Reader, hopefully.