1.10.0 contained a binary-incompatible change

[cpovirk]

870ece8#diff-4ca26bfec5c8a3f2731fb1662b1b40beL61 changed the return type of ClassName.withoutAnnotations():

https://abi-laboratory.pro/index.php?view=compat_report&lang=java&l=javapoet&v1=1.9.0&v2=1.10.0&obj=ad89e&kind=bin#Method_Problems_High

I noticed this because, in our project, Maven was choosing the older JavaPoet version from one of our annotation processors instead of the newer version from another. I can fix the problem for us by overriding to the new version (which is the right thing to do, anyway), but in theory, there could be a problem if some annotation processor were compiled against the old version and another against the new. Of course the old one should update and recompile, but presumably the intention was to maintain binary compatibility.

I also see a report here: https://stackoverflow.com/q/57490437/28465
And possibly this is similar: apollographql/apollo-kotlin#1113

I have a PR underway.

[cpovirk]

(I am a little confused because I thought that the supermethod forced the compiler to generate a bridge method already, but either it's not there, or it's not being selected for some reason....)

[JakeWharton]

But the change was a covariant specialization which shouldn't cause compatibility in practice, right?

[cpovirk]

Oh, wait, yeah, the bridge method is already there. The problem, again, is Maven's choice of the old version. I'm surprised that the ABI Tracker is getting it wrong.

Given that, the error is what you'd expect:

java.lang.NoSuchMethodError: com.squareup.javapoet.ClassName.withoutAnnotations()Lcom/squareup/javapoet/ClassName;

I'd gotten confused and thought the report was:

java.lang.NoSuchMethodError: com.squareup.javapoet.ClassName.withoutAnnotations()Lcom/squareup/javapoet/TypeName;

Sorry for the noise.

[cpovirk]

(There's already an issue for the ABI Tracker: lvc/japi-compliance-checker#50)