Java version requirements

[snazy]

It seems there's a mismatch between the "wanted" Java version for code compilation and the actually referenced code (like Stream.toList() since 16) - not a big deal, since the project's fresh. But I think we should define some rules for this.

Generally, it feels appropriate to distinguish between code that's only intended for the Polaris service and code that can be used by clients.

For the service side, going with Java 17 or even 21, seems reasonable.
For client dependencies (pulled in from downstream projects), sticking to Java 11 feels nicer.

WDYT? Thoughts?

[eric-maynard]

+1 to your suggestion here. 11 for clients, 21 for the service seems reasonable to me.

[adutra]

+1 to your suggestion.

it's roughly what we have now, but we don't enforce any API checks during build. Any reason why we are currently using sourceCompatibility + targetCompatibility instead of the release flag, or a toolchain?

[collado-mike]

In full transparency, we have an internal dependency on the JDK 11 build of the core jar, but we only use a subset of the library, which is why the 17/21 library methods have mostly gone unnoticed. For the service code itself, there's no reason to not use 21, but I'd like polaris-core to remain fairly generic so increasing compatibility is my preference.

So, if by "client dependencies" you mean polaris-core and possibly a Java client library, I fully agree JDK 11 is great. And I love the pattern matching in 21, so...

[snazy]

That's exactly the goal :)

An approach is in #106

[snazy]

The change #106 has been merged, so I'm closing this discussion.

[bayramtturgutt]

@snazy, it sounds like you’re on the right track with your approach. For your service-side code, targeting Java 17 or 21 is a good choice, as it provides access to the latest language features and enhancements. This can improve performance and maintainability while aligning with modern practices.

For client-side code and dependencies, sticking to Java 11 is a sensible decision. It helps ensure compatibility with a wider range of environments and reduces the risk of integration issues with clients who may not have upgraded to newer Java versions.

This dual approach allows you to leverage advanced features where beneficial while maintaining broader compatibility for clients. It’s a strategic balance that should serve your project well.