japicmp

japicmp copied to clipboard

The following project compiles a source file once as Java 7 bytecode, and then the same code as Java 8 bytecode. It then compares the resulting jar files with japicmp. Somewhat surprisingly, the classes are considered to be binary compatible, even though Java 8 bytecode obviously won't run on a Java 7 JRE.

https://github.com/io7m/japicmp-check-20170406

I'm not sure if this check would be outside of scope of japicmp. I consider the bytecode version to be part of the public API, but I can understand that many people might not see it that way.

This seems to be more suited to the maven-enforcer-plugin in scope, and may be possible already:

https://maven.apache.org/enforcer/maven-enforcer-plugin/usage.html

I'm not sure about that. Unless I'm mistaken, to use the enforcer plugin to do this, the rule implementation would have to implement the infrastructure needed to check the current bytecode against the previous published jar artifact. That's quite a lot of work to do something that japicmp already does.

Does javassist not expose bytecode versions in its API?

As javassist exposes the version of the class file format, japicmp can evaluate this. I have implemented a check for a version change. The HTML report as well as the diff report now output a modification if the class file format version changed:

***! CLASS FILE FORMAT VERSION: 52.0 <- 50.0

I could additionally implement a new flag for the maven plugin / CLI tool which breaks the build if the major part of this version changes, but I doubt that someone will use it because changes in the class file format are normally an explicit change that is wanted by the team and it would be annoying if the build fails then.

I'd like to break builds when class file format changes in combination with semantic versioning unless the major version is changed.