The old Groovy trace assertions were more readable...

Well I don't think it's clear-cut :) They're definitely less text, but I think one of the intentiona. points of assertj is to make the assertions closer to English - I guess I'm fairly used to our groovy assertions by now but even so, but even when I read these Java ones, I feel like it's much easier to just skim through since the English is so easy to parse compared to the programming DSL. Writability would be terrible if having to write all that English out, but auto completion made it actually easier for me. This is only one example though and I don't want to overgeneralize yet.

WDYT about writing our instrumentation tests in kotlin

But of course this could be a good option too. Downsides are

1. Still not Java like our codebase, so the contributor experience for Java authors isn't improved. Actually it might be worse - while we use so much DSL that most of our Groovy looks nothing like Java, actually Groovy being mostly a superset of Java can be familiar too. private static final works, while companion object is foreign to Java developers

2. Slower compiles so slower builds. Much less of a problem just documenting it

3. Maintaining the kotlin wrapper. For external instrumentation that want to write tests with Kotlin, it can be useful anyways which is nice, but in practice, I wonder how many would. E.g., Spring, Vert.X, Couchbase, Camel are a few external instrumentations I've seen but my gut tells me none of these projects would write tests in Kotlin for the instrumentation. If the wrapper is basically only for us, it could be pretty low bang for buck.

So tradeoff vs potential readability improvements - I think it would mostly be less indents and periods. Of course, if this is the only way to get rid of Groovy it is still a good way :P

They're definitely less text, but I think one of the intentiona. points of assertj is to make the assertions closer to English - I guess I'm fairly used to our groovy assertions by now but even so, but even when I read these Java ones, I feel like it's much easier to just skim through since the English is so easy to parse compared to the programming DSL.

They are closer to English, I definitely agree with that, but I'm not that sure whether it's a good thing - what I liked more about the "old" groovy assertions that they were less visually cluttered, you almost didn't even have to read them, the structure of the code (e.g. indentation for trace/span/attributes...) told you a bit before you even started reading what's inside.

Although maybe this gets a bit better if we work on the SDK assertions - lots of indentation and nesting comes from those .somethingSomethingSatisfying(span -> assertThat(span)...) calls that could be made a bit "flatter".

1. Still not Java like our codebase, so the contributor experience for Java authors isn't improved. Actually it might be worse - while we use so much DSL that most of our Groovy looks nothing like Java, actually Groovy being mostly a superset of Java can be familiar too. private static final works, while companion object is foreign to Java developers

That's true, Kotlin is a pretty different language... I'm fairly comfortable with it myself, but I can understand if we do not want to introduce it to this project. Anyway, that's just an idea, something to keep in the back of mind - maybe it's worth trying out, maybe it's not really worth the effort of learning a significantly different language.

3. If the wrapper is basically only for us, it could be pretty low bang for buck.

Yep, I thought mostly of our use case to be honest - I'm not sure if anybody else will want to use them.

Sure! Go ahead - we can't fix those Java assertions in this single PR, that needs some separate effort.

Just for the record: I don't like java assertions :)