The Wrath of Indonesia: JavaX -> Jakarta Migration

[jeremyk-91]

Goals (and why):

• Get on latest version of conjure-java-runtime

Implementation Description (bullets):

• Upgrade CJR versions.
• But this has transitives that break: Tritium and Jersey classes
• And this has further transitives: Dropwizard and its role in testing
• And that has a transitive effect: WireMock
• This PR resolves all of the aforementioned transitives. Thankfully the WireMock folks prepped a fat jar.
• I validated that we don't have cases where both JavaX and Jakarta things live on the classpath.

Testing (What was existing testing like? What have you done to improve it?):

• Existing tests, for general integrity of library stack
• I used baseline-class-uniqueness to validate that no JavaX and Jakarta things simultaneously live on the classpath. I did not leave it there as there were unrelated issues between AssertJ and ByteBuddy that I don't have the bandwidth to resolve right now.

Concerns (what feedback would you like?):

• While the tests work, I still have a feeling that some of the HTTP stack stuff is risky, especially since we bumped Dropwizard through two major versions. The scary dependency-resolution problems I had would not affect prod code, so I'm a bit less worried, but that's worth validating.

Where should we start reviewing?: versions.props

Priority (whenever / two weeks / yesterday): this week, if not in by tomorrow we should probably go with #4655 first

[changelog-app]

Generate changelog in changelog/@unreleased

Type

• Feature
• Improvement
• Fix
• Break
• Deprecation
• Manual task
• Migration

Description

Conjure Java Runtime is upgraded to 4.70.1.

Check the box to generate changelog(s)

• Generate changelog entry

[iamdanfox]

Is there a plan to get onto GCV? having such a long list of forces in versions.props is a little scary :/

[jkozlowski]

I think we should pull this into an internal product to just sanity check it starts up alright?

[jkozlowski]

Will this not effectively cause a bump in version for anyone that consumes atlasdb?

[jeremyk-91]

Yes, it will. I'll see if we can separate the test and compile classpaths.

[j-baker]

we can't be on dropwizard metrics 4

[j-baker]

it has enough breaking changes here

[jeremyk-91]

Now we're not. I went back to metrics 3

[gmaretic]

Approving contingent on it working on internal product

[jeremyk-91]

Validated on internal ski product in deployment to an internal stack. Pressing the big red button ™️

[jeremyk-91]

GCV: I'll open a task for tracking, it's probably worth doing soon. I think it's fair to say someone will look at this in the next 1-2 weeks, though I don't know how deep that rabbithole goes, so I can't commit the team to doing it in that time span.

[svc-autorelease]

Released 0.198.7