Replace Deprecated methods removed as 'unused'

[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.

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.

[Brent Easton]

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

[Brent Easton]

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.

[Flint1b]

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..

[Flint1b]

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.

[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.

[uckelman]

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.

[uckelman]

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.

[Tim M]

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

http://www.vassalengine.org/wiki/Module ... _and_Files

If people cant be bothered to read *'em as the saying goes...

[Flint1b]

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

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.

[Brent Easton]

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.

[uckelman]

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.

[Brent Easton]

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.

[uckelman]

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?

[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?

Possible, yes, but is it worth the trouble?