I’ve seen twice now an unexpected problem flagged up by the Removed and Deprecated Code checker.
E.g.:
Removed classes, methods, and fields in C:\Battlestar_Galactica_FFG_4.6.41.vmod
(used by => removed item, version when removed
VASSAL.build.GameModule => VASSAL.Info.compareVersions(java.lang.String, java.lang.String), 3.6.0
VASSAL.build.GameModule => VASSAL.build.GameModule.getGlobalPrefs(), 3.6.0
VASSAL.build.GameModule => VASSAL.tools.ArchiveWriter.write(boolean), 3.6.0
The class on the left of each arrow is the class using the thing on the right. The checker looks only at custom classes which are in the module being loaded. But look! In the above case, the calling classes appear to be in Vassal. That is not supposed to happen.
Appearances are deceiving in this case. VASSAL.build.GameModule from 3.6.5 does not call any of those removed methods, and the scanner couldn’t be finding that anyway as it doesn’t scan any of Vassal’s own files. What is actually happening here is that someone has copied some of Vassal’s class files into the module, which have since gone stale, and the removal checker is finding those.
You should never, never, never have copies of classes from Vassal inside a module. The best thing that can ever happen from doing that is nothing. On bad days, you may end up with bizarre problems due to loading stale versions of those classes from the module, or in this case, the module won’t load.
Fortunately, if you’re maintaining a module where this has happened, the solution is simple: Open your module with a ZIP archiving program and remove all class files from your module which aren’t part of its custom code.