Replace Deprecated methods removed as 'unused'

I think we need to replace all of the ‘unused’ Deprecated methods that where removed. Two reasons:

  1. The method used to determine they where unused does not take into account the substantial number of Vassal modules that are not hosted on the Vassal website.
  2. The method used does not work for modules that are hosted on the Vassal website.

All of my GTS modules that are hosted on the Vassal website and use Map.componentRectangle() that has been removed.

If we release 3.3.3 like this, we will be inundated with broken module reports.

Also missing that I use is
AbstractBuildable.getComponents()
AbstractBuildable.getAllDescendantComponents()

Ok, not as bad as I thought. My modules are not affected. The code throwing errors was written years ago for modules that not hosted on Vassal.

But that would mean there is no way of telling what modules use, no way of ever removing any deprecated stuff, not necessary to even mark stuff as deprecated as it will never be removed anyways, and each and every public and protected field is chiseled in stone and can never be changed or removed.

And new protected-access stuff keeps getting added every day without any thoughts being spent about whether it’s even necessary to make it protected. Things are protected by default, as if there is no private-level visibility in the language syntax…

Oh and of course, better not write any improved methods and deprecate old methods, since the old ones will have to stay in the code forever, and having both old and new methods for the same things is only making it worse.

Let’s take all the deprecated methods back, and also remove all the new methods that have been written, all these List-access methods for instance that replace the old array-based or enumeration-based access.

Alternatively, we remove even more deprecated stuff.

If I learned anything good and useful while working for big corporates, it’s that sometimes it’s better to drive the car into the wall, for people to start noticing and start working on the important things.

If these “rogue” module developers that don’t host on Vassal website will finally show up and complain that their old-ass unmaintained modules stopped working, we will get the chance to tell them to a) host their module on Vassal and b) maintain it properly and stop forcing us to support deprecated stuff for all eternity.

Thus spake Brent Easton:

I think we need to replace all of the ‘unused’ Deprecated methods that
where removed. Two reasons:

  1. The method used to determine they where unused does not take into
    account the substantial number of Vassal modules that are not hosted on
    the Vassal website.
  2. The method used does not work for modules that are hosted on the
    Vassal website.

Are sure it doens’t work?

Do we know why it doesn’t work?

Can we find something which does work?


J.

Thus spake Flint1b:

Alternatively, we remove even more deprecated stuff.

If I learned anything good and useful while working for big corporates,
it’s that sometimes it’s better to drive the car into the wall, for
people to start noticing and start working on the important things.

If these “rogue” module developers that don’t host on Vassal website
will finally show up and complain that their old-ass unmaintained
modules stopped working, we will get the chance to tell them to a) host
their module on Vassal and b) maintain it properly and stop forcing us
to support deprecated stuff for all eternity.

I would like to avoid spending a massive amount of time dealing with
module breakage, as this will involve many people who are angry or
unable to deal with it and who will blame us for it, rightly or wrongly.

Propose a way where that won’t be the result.


J.

I thought we already covered this a long time ago here

vassalengine.org/wiki/Module … _and_Files

If people cant be bothered to read *'em as the saying goes… :slight_smile:

Tell them to deliver their modules together with the version of the Vassal library that supports their modules. Just like everyone else in the software development world dies. There are libraries in Vassal too, and we deliver the versions that Vassal was developed against, we wouldn’t expect the Vassal code to work automatically with all future versions of these libraries would we??

Or, bend over, take the path of the least resistance, submit to the will of the minorities, and do things unlike everyone else in the software world does.

My follow up comment may not have been clear.

I believe the dependency check of modules hosted on Vassal DID work successfully.

I am not against removing the old cruft, however, it might be polite to at least give the off-site maintainers some official warning before doing so. Whether they see or take heed of that warning is not our problem.

Thus spake Brent Easton:

My follow up comment may not have been clear.

I believe the dependency check of modules hosted on Vassal DID work
successfully.

Ah, ok. I thought you were saying that the dep check was incorrect.

That’s good to know we’re not facing that problem.


J.

Yeah, sorry about that. I had older versions of code with the same class names that where not compiling and jumped to conclusions. These versions are only used in some modules I know are stored off-site.

Can we display a warning dialog for modules using deprecated classes or methods, like we do for modules compiled for versions of Java newer than the minimum we support?

You mean like, at runtime find out which of our stuff is deprecated, then find out whether the currently running module uses any of it?

Possible, yes, but is it worth the trouble?

Thus spake Flint1b:

You mean like, at runtime find out which of our stuff is deprecated,
then find out whether the currently running module uses any of it?

Something like that, yes.

If we could display a dialog notifying the user that a module uses
something deprecated and they should contact the module’s maintainer
about that, I have good reason to believe modules will get adjusted.

Possible, yes, but is it worth the trouble?

That depends on how much work it is, and how much work it would save.
I don’t have a sense of what the ways of doing it are and how much
work they would be.


J.

First thing that comes to mind is to use this deprecate-analysis tool that I’ve found, the one that we used to determine the unused dependencies. Take that in as a library and write code on top of that, basically doing the same thing we did by calling that tool from a shell script. This would probably be the easiest to implement.

Other options would be to use some other code analysis library, like asm or cglib, I think we already have asm (or was it cglib?) in the libraries, beanshell brings it along. But we would have to reinvent the wheel with that, write the whole analysis code from scratch.

Thus spake Flint1b:

First thing that comes to mind is to use this deprecate-analysis tool
that I’ve found, the one that we used to determine the unused
dependencies. Take that in as a library and write code on top of that,
basically doing the same thing we did by calling that tool from a shell
script. This would probably be the easiest to implement.

Other options would be to use some other code analysis library, like asm
or cglib, I think we already have asm (or was it cglib?) in the
libraries, beanshell brings it along. But we would have to reinvent the
wheel with that, write the whole analysis code from scratch.

Something depends on cglib… possibly mockito?

I suppose the stupid-simple thing would be to add a line to each of the
deprecated methods which raises the disableable problem dialog.


J.

How sure are you that the users would pay attention to technobabble and contact the module developers? I can imagine they will be frightened the first couple times but realize that nothing is broken and they can still play as usual, then get used to it and just click it away.

I am still more convinced by the “crash the car into the wall” strategy, this is what is needed to get the module developers to wake up. I would just prepare for this a little, maybe sth like a big announcement “in case your module doesn’t work with new version - a) here is Vassal 3.2.17 download, use that b) contact module developers”.

Thus spake Flint1b:

How sure are you that the users would pay attention to technobabble and
contact the module developers? I can imagine they will be frightened the
first couple times but realize that nothing is broken and they can still
play as usual, then get used to it and just click it away.

  • Module developers are likely to see the message themselves when they
    try their modules. Some of the problems will be fixed by module
    developers as a result.

  • It’s not necessary for every user to understand the message for it to
    be effective. It won’t take very many users contacting module designers
    about problems before it becomes quite annoying for them, to the point
    that it will be less annoying to fix the problem.

We haven’t had many questions about custom classes being compiled with
the wrong version of Java since we added the warning dialog for that.
It’s a similar situation, so I expect a similar result if we add a
warning for using deprecated methods and classes.

I am still more convinced by the “crash the car into the wall” strategy,
this is what is needed to get the module developers to wake up. I would
just prepare for this a little, maybe sth like a big announcement “in
case your module doesn’t work with new version - a) here is Vassal
3.2.17 download, use that b) contact module developers”.

Removing currently deprecated methods is that strategy. What we’re
talking about is how to let module designers and users know what to do in
a way that doesn’t ruffle a lot of feathers or become a huge time suck
for us.


J.