"Out Of Date Custom Code"


Upon upgrading to Vassal 3.4.2, when I opened one of my Up Front modules, I got the following “warning”:

- [Out Of Date Custom Code] This module contains custom code that is calling the VASSAL function VASSAL.build.GameModule.getFrame. This function is scheduled to be removed from VASSAL after 6-Aug-2021 and this module will cease to function.

What does this mean and how do I go about fixing it? And why are you going to remove the function it refers to? This seems to be a problem in all the modules based on and including the original Up Front module. Both those I have tweaked and those I have kept in their original form (Up Front and Up Front Nam).

Will I just have to roll back to an older version of Vassal when next August comes?



This means that the method “public JFrame VASSAL.build.GameModule.getFrame()” is scheduled to be removed after 6-Aug-2021, and the module will cease to function with Vassal versions released after that date.

We will remove this method because it is too generic, and we offer a better method as a replacement: “public PlayerWindow Vassal.build.GameModule.getPlayerWindow()”. The PlayerWindow is also a JFrame. We documented this in Vassal’s code, right on top of the deprecated method: github.com/vassalengine/vassal/ … .java#L245. Note how it says “@deprecated use {@link #getPlayerWindow()}”

The best you can do is to replace the call to “getFrame()” with a call to “getPlayerWindow()”, as suggested in the Javadoc.

In case this is too technical, the source for the custom code is not available anymore, decompiling the bytecode is next to impossible, and everything I wrote sounds like gibberish, please say so and we will think about another way of helping you.

Thanks for the answer, but I didn’t understand a thing of it. Sorry.
I don’t know what custom code is. I don’t know what it does in the game. And I don’t have the faintest idea of how I have to go about to replace the call “getFrame()” with “getPlayerWindow()” as I cannot recall to ever have seen these phrases when I have worked in any of the modules.

Hope you are able to enlighten me. The best would be a step by step description “for dummies”. Do this, then this, then that etc.


Well, this was an interesting experience. I looked up these modules, two hours later I have learned some new stuff about Java internals, and fixed the custom code for you. In theory. I have not actually tested it, I do not guarantee that it will run.

I was not aware of how involved this can be, now in retrospect, I recommend the following, a step by step guide:

  1. If you maintain a module which has custom code, and you don’t know what custom code is, run away
  2. If you are still there, and you know roughly what Java is, or any other high-level programming language, still run away
  3. If you are still there, know some Java basics, run away
  4. If you are still there, know how to setup a Java project, use a Java IDE, and are willing to learn Java internals, only then you are actually able to maintain such a module

I present you two files:
[attachment=1]upfront-custom-code.zip[/attachment] this is the source for the custom code, it is for future reference and maintaining the module, you can (=should) put it right inside the module zip file for future maintainers

[attachment=0]UpFront-compiled.zip[/attachment] this is the compiled custom code, you will see an /UpFront folder inside the modules and several .class files in there, remove them all and replace with the files from this zip

I maintain this module and yes I do know how to do step 4.

I have not done so because

  1. I have been waiting for V4 (+10 years now). I stopped working in Eclipse 6+ years back

  2. As I recall this custom class “messenger” was written by Brent and this was done back on Vassal 1.2 (I still have a copy of 1.2. We go back a very long way with vassal, was 2002 iirc), the class was a simple thing for reporting and had long since been incorporated into vassal after 2.0 i think, but it never broke until now after Vassal 3.4 so there never was a need to update it.

  3. Since the development plan has now been updated referring to V3.5 and V3.6 but alas no V4, I’ve just given up. After 18 years, Im just happy to manage the module pages these past 10.

Thus spake Tim M:

  1. Since the development plan has now been updated referring to V3.5 and
    V3.6 but alas no V4, I’ve just given up. After 18 years, Im just happy
    to manage the module pages these past 10.

V4 planning is waiting on me, and it’s next on my list after 3.4.3 is
released. I haven’t put anything on that planning page myself yet.


Flint1b wrote:

I decided to try this, but the module I opened had more .class files in it that what I could find in the zip file from Flint1b.

Now what?


That’s actually fine in this case – what Flint said to do (remove all the old ones and insert all the new ones) will work right. Java compilers sometimes split classes into multiple files, and I think Flint cleaned some stuff up, but it looks like the right number of “main” files to me.

Yes, good that you noticed it, means you found all the right folders and files and paid attention to what you’re doing. And in this case it’s normal that there are fewer class files.

If you’re interested in details: I turned some anonymous classes into lambdas, and the compiler doesn’t generate .class files for lambdas like it does for anonymous classes.

So, almost a year has passed since the last word was written in this thread. Sorry for not following up earlier, but now the date draws closer and I decided to have a go. I did as suggested. Removed the old files, inserted the new ones, zipped the whole thing and renamed it. vmod. And the module still worked! Only catch is that the “Out of Data Custom Code” warning still appears when the module is started. I assume and hope this is because the warning is not a result of the system analyzing all modules before they are opened, but rather the warning has been attached by default to certain modules known to contain this old custom code. Anyway, I’ll try opening the testmodule again after August 6. If it still works, good. Then I will update the Vassal version when a new one comes out after August 6. If it still works I’ll do this exercise to all my modules with this issue and play on happily. If it doesn’t work, I’ll roll back to an older Vassal version and play on happily, never updating Vassal again.

Thanks for all the halp so far! I’ll post the outcome here. :slight_smile:


No, “Out of Date Custom Code” warnings are triggered by the code they’re attached to being loaded. If you’re seeing these, you’re still using the code you’re being warned about.

We haven’t removed any of the deprecated code—yet. But anything which has passed the date given is fair game for being removed. The best solution is to look at the messages (which are present with more detail in the errorLog) and replace the deprecated function calls.

The only support you’ll get for older versions of VASSAL is a suggestion that you upgrade to the current version. Remaining on an old version indefinitely is not a good strategy. The easiest time to replace deprecated code is right away, when people still remember how. Waiting only increases the difficulty. If you post what’s in the errorLog here, we might be able to suggest what you need to do.

I don’t get any error logs as far as I can see. The modules work as they use to without errors. I only get the warning when I start the module. And I tried to solve it as you can see earlier in the thread. Using the replacement files that Flint was so kind to make. I don’t know what more to do at the moment, but if the modules start to fail, I’ll refer to eventual error logs here.


There is always an errorLog. One place you can see it is Help > Show Error Log in the Module Manager. After opening your module, post the contents of the errorLog here. I’d like to see what’s there now, with 3.5.8, not what was there a year ago.

We’re presently discussing removing anything deprecated more than a year ago, so you might find that 3.5.8 is the end of the line unless you update your custom code—which is not likely to be difficult, so I strongly urge you to pursue this.

Thanks so much for trying to help me out.

I currently run Vassal 3.4.2 as I have not been automatically urged to update to a newer version. Earlier I used to be. So I have assumed that I was running the latest one. Obviously not. However, I know that my modules work in this one and have been happy with that so far.

I would very much like to try to update my custom code, but I don’t know how and I don’t know what a custome code is or what it does. I thought that updating it was what Flint tried to help me with as he postet the new .class files for me earlier in the thread.

I checked the error log and here is what is says (quite a lot. I don’t know what is important and what is not):

2021-08-01 22:02:16,144 [0-main] INFO VASSAL.launch.StartUp - Starting
2021-08-01 22:02:16,144 [0-main] INFO VASSAL.launch.StartUp - OS Windows 10 10.0
2021-08-01 22:02:16,144 [0-main] INFO VASSAL.launch.StartUp - Java version 14.0.2
2021-08-01 22:02:16,144 [0-main] INFO VASSAL.launch.StartUp - VASSAL version 3.4.2
2021-08-01 22:02:16,229 [0-AWT-EventQueue-0] INFO VASSAL.launch.ModuleManager - Manager
2021-08-01 22:02:20,021 [0-SwingWorker-pool-2-thread-1] INFO VASSAL.launch.AbstractLaunchAction - Loading module file C:\Roar\VASSAL\VUF\Moduletest Campaign\Up Front Campaign Extended.vmod
2021-08-01 22:02:20,475 [0-SwingWorker-pool-2-thread-1] INFO VASSAL.launch.TilingHandler - No images to tile.
2021-08-01 22:02:20,475 [0-SwingWorker-pool-2-thread-1] INFO VASSAL.launch.AbstractLaunchAction - Loading module Up Front Campaign Extended
2021-08-01 22:02:20,491 [0-SwingWorker-pool-2-thread-1] INFO VASSAL.tools.io.ProcessLauncher - launching C:\Program Files (x86)\VASSAL-3.4.2\jre\bin\java -Xms256M -Xmx512M -DVASSAL.id=1 -DVASSAL.port=64917 -Duser.home=C:\Users\Roar -Duser.dir=C:\Program Files (x86)\VASSAL-3.4.2 -cp lib\Vengine.jar VASSAL.launch.Player --load – C:\Roar\VASSAL\VUF\Moduletest Campaign\Up Front Campaign Extended.vmod
2021-08-01 22:02:21,347 [1-main] INFO VASSAL.launch.StartUp - Starting
2021-08-01 22:02:21,347 [1-main] INFO VASSAL.launch.StartUp - OS Windows 10 10.0
2021-08-01 22:02:21,347 [1-main] INFO VASSAL.launch.StartUp - Java version 14.0.2
2021-08-01 22:02:21,347 [1-main] INFO VASSAL.launch.StartUp - VASSAL version 3.4.2
2021-08-01 22:02:21,347 [1-main] INFO VASSAL.launch.Launcher - Player
2021-08-01 22:02:23,394 [1-AWT-EventQueue-0] WARN VASSAL.launch.BasicModule - Up Front Campaign Extended version 1.1

There aren’t any deprecation warnings in that errorLog, probably because it’s from 3.4.2. I need an errorLog from 3.5.8.

Of course I can upgrade to 3.5.8, but will the modules still work then? If I understand it correctly the codes aren’t removed until the next version after that.


Finding that out is one reason for upgrading to 3.5.8.

That’s correct—we haven’t removed anything that was deprecated in 2020 yet.

Let’s back up a moment.

If I am understanding correctly, you were getting an Out of Date Custom Code warning from 3.4.2. Then you replaced the custom code with what Flint posted, and now you’re not getting that warning from 3.4.2.

If I have that right, then I’m not sure what problem we’re trying to solve here. If you’re no longer having these warnings, isn’t the problem already solved for you?

I was getting an Out of Date Custom Code warning from 3.4.2. I did replace the custom code with the files from Flint. And I am still getting the warning from 3.4.2.


I see no warning in the errorLog you posted. Please try loading your module and using it to the point that you get an Out of Date Custom Code warning in 3.5.8 and post an errorLog from that.