migrate everything from java 17 to java 21

[postamar]

This was fairly straightforward to do once the CDK dependencies were cleaned up.

This PR is best reviewed commit-by-commit.

While this PR triggers the connectors' CI, it does not change the connector docker images in any meaningful way. I tested that airbyte-ci connectors --name=source-postgres build and test work properly.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
airbyte-docs	⬜️ Ignored (Inspect)	Visit Preview		Feb 10, 2024 0:40am

[rodireich]

What does this practically mean for devs?
Need to have openjdk 21 installed to compile?

[postamar]

What does this practically mean for devs?
Need to have openjdk 21 installed to compile?

Excellent question! The answer is yes, and:

• you also want 21 to be the default jdk;
• you might need to install a more recent intellij and tell it to use the 21 jdk.

But that should be it. FYI, in my shell config I have

export JDK_VERSION=21
export JAVA_HOME="$(/usr/libexec/java_home -v $JDK_VERSION)"

Note that airbyte-ci won't care about whether java 21 is installed or not, since it does everything in containers.

[postamar]

Thanks for the reviews! I'll merge this later this evening to minimize the disruption. It'll be a force-merge: there are no significant connector changes which warrant publication.

[stephane-airbyte]

@postamar I think you should merge this in different PRs. The 1st PR should be for airbyte-ci. The 2nd should be the github actions. And once that's stable, we can change everything else, no?

[postamar]

I see your point, I'd considered it independently, but came to the opposite conclusion. If we apply the airbyte-ci changes, which change the java runtime of the connectors, and then apply the compilation target changes later on, and then have to worry about this interim period where connectors get published with 17 bytecode but packaged in images with 21 runtimes. We could mitigate this by disabling the publishing workflow, but this still creates some risk if we're to revert one of these PRs but not the other. Hence I believe that merging (and possibly reverting) these changes atomically is actually less risky because far easier to reason about.

[gisripa]

looks good on destinations side. destination-iceberg is failing on master too https://connectors.airbyte.com/files/generated_reports/test_summary/destination-iceberg/index.html

[stephane-airbyte]

You can compile with a 17 target and run on 21. That’s one of the strong guarantees of java

…

--- Stephane GeneixTechnical Support GitHub <https://github.com/airbytehq/airbyte> | Twitter <https://twitter.com/AirbyteHQ> | LinkedIn <https://www.linkedin.com/company/airbytehq/> We're hiring, come work with me! <https://airbyte.io/careers> [image: 🚀]

On Fri, Feb 9, 2024 at 12:46 PM Marius Posta ***@***.***> wrote: I see your point, I'd considered it independently, but came to the opposite conclusion. If we apply the airbyte-ci changes, which change the java runtime of the connectors, and then apply the compilation target changes later on, and then have to worry about this interim period where connectors get published with 17 bytecode but packaged in images with 21 runtimes. We could mitigate this by disabling the publishing workflow, but this still creates some risk if we're to revert one of these PRs but not the other. Hence I believe that merging (and possibly reverting) these changes atomically is actually less risky because far easier to reason about. — Reply to this email directly, view it on GitHub <#35103 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BDDFPOC2H5FV3BWIOILAVALYS2DJ5AVCNFSM6AAAAABDBWXM7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZWGU4DAMZYGI> . You are receiving this because your review was requested.Message ID: ***@***.***>

[postamar]

/approve-and-merge reason="unrelated connector CI failures"

[octavia-approvington]

What are we doing again?