Use uniform Assertions AssertJ class

[ksobolew]

Description

According to javadocs, the AssertionsFor(Class|Interface)Types were introduced to circumvent type inference issues with generic classes in Java 8. But it seems that we don't have these issues in our code base, so it looks like importing from these classes was just a mistake.

Additional context and related issues

These classes also have somewhat impoverished API. That's actually how I found it - I couldn't find a method I was expecting in one place.

Release notes

(x) This is not user-visible or is docs only, and no release notes are required.
( ) Release notes are required. Please propose a release note for me.
( ) Release notes are required, with the following suggested text:

# Section
* Fix some things. ({issue}`issuenumber`)

[wendigo]

I've killed a build, since master is broken due to compilation issue: #19014

[ksobolew]

Thanks, I'll rebase once the fix is merged.

[ksobolew]

Although funny thing is, it compiled for me locally?

[wendigo]

Did you rebase on master?

[ksobolew]

No, and this branch doesn't even include the faulty commit 🤔

[ksobolew]

Anyway, the fix is in so I'll just rebase.

[wendigo]

@ksobolew github always rebased on target branch when running CI

[ksobolew]

I see...

[ksobolew]

I want to add these classes to the banned imports list, but I'll need a fix in airbase first, so I'll make it a draft for now.

[wendigo]

Is this blocking this change from being merged @ksobolew ?

[ksobolew]

Nope, restrict-imports-enforcer-rule is broken and it's impossible to add additional RestrictImports rules in a child POM.

• All regular rules require only a single declaration; if multiple are present, only the first one is used
• But RestrictImports requires multiple declarations so that we can group them and assign different <reason>s for them
  • There's a possibility to use <group><group>...</group>...</groups>, but the groups are exclusive - only the one with the most-specific base package is chosen, the rest is ignored - while multiple RestrictImports are inclusive
• If we add combine.children="append" to the parent <rules> tag, we can add additional <RestrictImports> declarations, but everything else is broken, because the child POM adds additional declaration instead of merging with the parent one, so it breaks on the first bullet point above
• No other combination of combine.self="..." seems to make it work for <RestrictImports> and not for other rules

Note: there is one place in trino-base-jdbc where we do this (<rules combine.children="append">), but we don't risk breaking other rules there, so it's fine there. But it's not fine to do that for all modules.

[ksobolew]

Is this blocking this change from being merged @ksobolew ?

No, not blocking. I was just hoping to do it in one PR. But it can be merged as-is.

[wendigo]

@ksobolew we should add this rule to airbase

[wendigo]

@ksobolew do you want this change to be merged?

[ksobolew]

Yes, please :)

[ksobolew]

@ksobolew we should add this rule to airbase

👍

[ksobolew]

airlift/airbase#376