search

siom79 / japicmp

Comparison of two versions of a jar archive
https://siom79.github.io/japicmp
Apache License 2.0
694 stars 107 forks source link

False alarm: METHOD_NO_LONGER_VARARGS #393

Closed He-Pin closed 3 months ago

He-Pin commented 3 months ago

version: 0.20.0

The method is there, so this is a false alarm.

Reproduce progress:

  1. check out netty/netty 4.1 branch
  2. change the japicmp version to 0.20.0
  3. run japicmp check

Thanks for this great plugin, I find this when preparing a pr in: https://github.com/netty/netty/pull/13989

siom79 commented 3 months ago

Thanks for reporting.

The issues looks a bit weird. When debugging, it shows that in this line in the method extractVarargsModifier() the javassist library returns for behavior.getModifiers() the value 9 for the old version and 137 for the new version. And 137 & 128 means, that VARARGS is set in the new version but not in the old one. So from the point of japicmp it seems to be correct.

But if you compare both class files Unpooled.class, they are identical on each bit. So why does javassist read the value 9 in the old version and 137 in the new version?

He-Pin commented 3 months ago

Thanks for reporting.

The issues looks a bit weird. When debugging, it shows that in this line in the method extractVarargsModifier() the javassist library returns for behavior.getModifiers() the value 9 for the old version and 137 for the new version. And 137 & 128 means, that VARARGS is set in the new version but not in the old one. So from the point of japicmp it seems to be correct.

But if you compare both class files Unpooled.class, they are identical on each bit. So why does javassist read the value 9 in the old version and 137 in the new version?

Thanks for quick validation this, this maybe bump javasist version in later release ?I'm not an expert on this. But I checked 0.15.7, it works.

siom79 commented 3 months ago

1,5 hours later: There was an issue with matching the corresponding methods in case one method had a byte array as parameter (byte[]) and the other one an array of byte arrays with varargs (byte[]...). The algorithm did falsely match the wrong arguments (treating byte[]... the same as byte[]). Therefore, the code comparing the varargs bit in the modifiers did compare two different methods. :-)

I have fixed this with the last commit.

He-Pin commented 3 months ago

Thanks, do you plan a newer release soon, I would like to submit a pr in Netty for this.

siom79 commented 3 months ago

Released with 0.21.0.