https://github.com/onetable-io/onetable/blob/main/.azure-pipelines/workflows/compile-and-test.yml#L16-L17 might need to be changed to 1.8 as well.

@ksumit please check out the readme. You'll be using java 11 to compile.

@the-other-tim-brown is that restriction desirable? we are generating jdk8 builds only, hence this suggestion.

Java 11 is already 5 years old at this point. This is a new project. We arguably should use a newer version than 11 like 17 (trino is built with java 17 for example). The jars we produce are compatible with java 8 to allow for users to add these to their existing environments that may not have upgraded.

I chatted about this with @ashvina this morning. The production reality is that JDK8 is still the most in use (at least within bigdata ecosystem). We should compile the project against JDK8 to ensure we don't end up taking a dependency on a library that is only compatible with higher versions of JDK. Let's discuss this offline if we can find a middle ground where developers feel empowered to use a higher version of JDK for development but we are still guaranteeing a JDK8 compatible build output along with runtime dependencies being compatible with JDK8.

Can you share the market research/data on this?

The compiler should error out if we use any incompatible features since we use the release option instead of the source/target options.

This means that, unlike the [-source and -target options](https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html), the compiler will detect and generate an error when using APIs that don't exist in previous releases of Java SE.

Docs: https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-release.html