It might be useful if the module-info.class file was checked as well, it seems that is currently not the case.
If no /module-info.class file exists, it would be good to also check at /META-INF/versions/.../module-info.class. Many libraries use that approach to still target Java 8, but include a module-info.class when users use a newer Java version.
Some incompatible changes which come into my mind:
(?) Changing requires transitive <module> to requires <module>
Consumers have to add an requires <module> then to their module declaration if they are using that module.
(maybe not that dramatic if users are not expected to actually use that module in the first place, then they are not affected by this)
(?) Changing requires static <module> to requires <module>
This changes module from an optional to a required module at runtime.
(whether this is really an incompatibility might depend on which module it is; e.g. if it is part of the JRE then this might not matter since the module is always available at runtime)
Removing exports <package>
Changing unqualified exports <package> to qualified exports <package> to <module>[^1]
Removing opens <package>
Changing unqualified opens <package> to qualified opens <package> to <module>[^1]
(?) Removing a provides ...
(whether this is really an incompatibility depends on if this change actually removes functionality, or if for example there is still another service which provides the needed functionality)
Not sure if all of these are really major incompatibilities, or incompatibilities at all.
[^1]: Technically changes to the modules listed as to <module>, e.g. to mod_a, mod_b → to mod_c, could also cause incompatibilities. But that would only affect those modules (since other modules neither had access before nor after), so in most cases such a change would probably not matter much, especially since the listed modules are likely modules from the same organization.
It might be useful if the
module-info.classfile was checked as well, it seems that is currently not the case. If no/module-info.classfile exists, it would be good to also check at/META-INF/versions/.../module-info.class. Many libraries use that approach to still target Java 8, but include amodule-info.classwhen users use a newer Java version.Some incompatible changes which come into my mind:
openfrom the module declaration:requires transitive <module>torequires <module>Consumers have to add anrequires <module>then to their module declaration if they are using that module. (maybe not that dramatic if users are not expected to actually use that module in the first place, then they are not affected by this)requires static <module>torequires <module>This changes module from an optional to a required module at runtime. (whether this is really an incompatibility might depend on which module it is; e.g. if it is part of the JRE then this might not matter since the module is always available at runtime)exports <package>exports <package>to qualifiedexports <package> to <module>[^1]opens <package>opens <package>to qualifiedopens <package> to <module>[^1]provides ...(whether this is really an incompatibility depends on if this change actually removes functionality, or if for example there is still another service which provides the needed functionality)Not sure if all of these are really major incompatibilities, or incompatibilities at all.
[^1]: Technically changes to the modules listed as
to <module>, e.g.to mod_a, mod_b→to mod_c, could also cause incompatibilities. But that would only affect those modules (since other modules neither had access before nor after), so in most cases such a change would probably not matter much, especially since the listed modules are likely modules from the same organization.