I agree that deprecating code before removing it, when possible, is a very good thing to do. But it is not always possible. The ImageJ2/SciJava table code was an example of that. Particularly when type hierarchies change, deprecation may not be enough to preserve binary backwards compatibility.
And deprecation alone is not enough. Eventually, if those deprecated classes are ultimately removed, the plugins in question—which presumably have still not been updated since they “weren’t broken” and no one recompiled them, and maybe the facility engineer already left years ago—will stop working at that time. By and large, ImageJ’s solution since 1997—and the solution of many Java libraries—has been to never remove any API ever. My strategy for the ImageJ2 layer has been to move deprecated classes to a dedicated
imagej-deprecated library so that people still needing it can continue to use it. But keeping the deprecated functionality tested and working as the most recent code continues to progress does add to the maintenance burden.
ImageJ’s extensibility is the root of the problem here. We (the developers of various core libraries) can work very hard whenever an incompatibility is introduced to roll forward all affected downstream code across all of Fiji—and even beyond with community plugins to some extent—but there will always be things off our radar, such as non-public plugins and scripts.
We cannot keep this system 100% binary API compatible forever. These libraries have a massive public API footprint, and already some of them, including SciJava Common and ImageJ Ops, are at the point where another major design iteration is needed to support impending requirements. A lot of public API is going to break in the future. The best way I know to avoid being destroyed by the breakages is to make a tarball of Fiji that behaves the way you want/need, and save it with your analysis of the time.
I’d be very enthusiastic to discuss realistic ideas, suggestions, approaches, paradigms, etc., for improving this situation. But the pragmatic reality is tough: there is scarce funding for keeping ImageJ working in its current state without any “forward progress” from scientific and technical perspectives.