For the documentation what should I do? Should I copy paste the same documentation as for the other method?

Yes, I'd copy the existing documentation.

Yes, I'd copy the existing documentation.

Should I also mention the new method in the old methods description?

Should I also mention the new method in the old methods description?

Yes, you could add a @deprecated entry in the Javadoc similarly to what we have with AbstractThrowableAssert::getCause.

Now for unit tests should I also use similar unit tests as the old methods do? Or should I change the method calls in the tests to the new method?

Now for unit tests should I also use similar unit tests as the old methods do? Or should I change the method calls in the tests to the new method?

So I'll do the second thing?

Now for unit tests should I also use similar unit tests as the old methods do? Or should I change the method calls in the tests to the new method?

So I'll do the second thing?

Yes, changing the method calls in the tests to the new method is fine. Sorry for the late feedback!

I don't understand why some of the checks are failing

It's caused by the standard_assertions_and_bdd_assertions_should_have_the_same_non_assertions_methods test method in Assertions_sync_with_BDDAssertions_WithAssertions_and_soft_assertions_variants_Test.

To fix it, you need to add new entry point methods in BDDAssertions, in line with the changes you did in Assertions.

It's caused by the standard_assertions_and_bdd_assertions_should_have_the_same_non_assertions_methods test method in Assertions_sync_with_BDDAssertions_WithAssertions_and_soft_assertions_variants_Test.

To fix it, you need to add new entry point methods in BDDAssertions, in line with the changes you did in Assertions.

Thank you, I had overlooked the BDDAssertions.java file previously.
I also added a <p> tag in the documentations of the old methods after the deprecated marker, as the method description was coming on the same line otherwise.

@scordio Could you please approve the workflows? Thank you.

Technically speaking, the PR is not something "Kotlin requires".
The PR makes the code easier to use in Java as well: lambda body can be big, so the code is easier to follow if smaller arguments (e.g. Class) come before lambdas.

So I would suggest renaming the PR (and commits) to something like Move lambdas to last arguments of .....

I agree with @vlsi, also mentioned in #2821 (comment):

We believe that the readability of Java code can also benefit from this change.

PR renamed.

Bump

We should also add a Kotlin-based test as the whole topic started from there. I'll take care of it.