Applet upgrade procedure

[MonsterOfCookie]

Hey All.

Quick question with regarding applet binary upgrades.

If I want to release a new version of my applet, I assume it is best to release it with the jar name containing the version number to force the JRE to pull it down and ignore the other. Is this correct? Is there a way I can tell the JRE to invalidate the previous build and use the new one without having the user to change and local settings?

If this is possible, what are the knock on effects, if any, with regards to the classloader in currently running JRE? (if they are viewing the applet currently and refresh the page)

Cheers

James

[ra4king]

If your applet is running and you upload a new version, to upgrade you have to end the java.exe process and refresh the page. If you want to force using the new version without restarting Java, I think changing the name of the jar file and linking to that one in the HTML file will force it to pull the new one.

Hope that helps ;D

[Riven]

Open the Java Console, hit X and C: it will clear the classloader and clear the console.

[MonsterOfCookie]

Thanks ra4king that’s what I thought was going to be the case. Off the top of your head when they refresh the page would this cause a separate java process to spin up?

Riven, thanks for your input, but that requires input from the end user. I really don’t want them to go through a potential 4 step procedure when I update.

[Demonpants]

@MonsterOfCookie

Thanks ra4king that’s what I thought was going to be the case. Off the top of your head when they refresh the page would this cause a separate java process to spin up?

Riven, thanks for your input, but that requires input from the end user. I really don’t want them to go through a potential 4 step procedure when I update.

When you refresh the page, the previous java process will stop and a new one will start. Depending on their browser settings, they may or may not cache the old version of the applet, meaning they wouldn’t get the new one. In order to avoid this, you can do just what you asked - rename each successive update.

[ra4king]

@Eli Delventhal

@MonsterOfCookie

Thanks ra4king that’s what I thought was going to be the case. Off the top of your head when they refresh the page would this cause a separate java process to spin up?

Riven, thanks for your input, but that requires input from the end user. I really don’t want them to go through a potential 4 step procedure when I update.

When you refresh the page, the previous java process will stop and a new one will start. Depending on their browser settings, they may or may not cache the old version of the applet, meaning they wouldn’t get the new one. In order to avoid this, you can do just what you asked - rename each successive update.

The Java process does not stop when you refresh a page. If you close the tab, it will take a couple minutes until the Java process closes.
I never knew about the ‘X’ function in the console so Riven’s suggestion is the best.

[MonsterOfCookie]

From a development perspective yes Rivens way is perfectly useful. But I am thinking along the lines of a live environment, I really don’t want my players to have to open up the Java console every time I deploy.

[Demonpants]

The process stops for me unless the applet is doing something stupid. Even if it sometimes takes a second or two, I think you can consider this working for your purposes.

[Riven]

@Eli Delventhal

The process stops for me unless the applet is doing something stupid. Even if it sometimes takes a second or two, I think you can consider this working for your purposes.

As been said: it is normal behaviour for the JRE to linger around for minutes, even if the applets do a clean shutdown. Reloading an applet is horrible as you load it in the same classloader and all static fields will still be there. You really must ensure your applet is running isolated, for example by adding random/timestamp parameters to your jars: stuff.jar?rndm=… (generate this either clientside or serverside).

[ddyer]

the best procedure is to upload a completely new java hierarchy, then change the HTML
page that loads it to point to the new jar file. Browser caching is a real problem. You
cannot depend on the old applet becoming extinct in any particular timeframe.

[ra4king]

@ddyer

the best procedure is to upload a completely new java hierarchy, then change the HTML
page that loads it to point to the new jar file. Browser caching is a real problem. You
cannot depend on the old applet becoming extinct in any particular timeframe.

New Java hierarchy?
All you need is a different jar file name.

[ddyer]

@ra4king

@ddyer

the best procedure is to upload a completely new java hierarchy, then change the HTML
page that loads it to point to the new jar file. Browser caching is a real problem. You
cannot depend on the old applet becoming extinct in any particular timeframe.

New Java hierarchy?
All you need is a different jar file name.

Sure, if your whole applet is in one jar. Boardspace has about 40.

[ra4king]

40? Overkill much? ;D

[Demonpants]

@ra4king

40? Overkill much? ;D

Well you have the advantage of making load times a lot less when you update individual pieces.

A model I have implemented but never used basically has one JAR for code, one for the initial data bundle (sounds and images), and then a new data bundle JAR every time I release an update. Having the user reload the code JAR every time is no problem at all, and being able to just load a new bundle each time really helps with download time. The only real trick you need is if you have AssetA.jpg in bundle 1 and also in bundle 5, you need to make sure to use the one in bundle 5 as that’s more recent.

[Riven]

@Eli Delventhal

The only real trick you need is if you have AssetA.jpg in bundle 1 and also in bundle 5, you need to make sure to use the one in bundle 5 as that’s more recent.

Which can be achieved by ordering the jars in the classpath.

[Mike]

If you have access to php on the server it’s also a good idea to call the jar with something like:

applet.jar?version=<?php echo filemtime("applet.jar"); ?>

It’ll append the last modified date to the jar and it therefore won’t be cached longer than necessary. That saves you having to manually rename the applet/applet tag every time…

Mike

[ddyer]

@ra4king

40? Overkill much? ;D

That’s one per game plus a few that run the common parts of the site. It minimizes the user’s waiting time if they only have to download the games they actually play.

[Demonpants]

@Riven

@Eli Delventhal

The only real trick you need is if you have AssetA.jpg in bundle 1 and also in bundle 5, you need to make sure to use the one in bundle 5 as that’s more recent.

Which can be achieved by ordering the jars in the classpath.

Oh, that’s cool. I didn’t know it was able to do that. I assume the lastmost jars in the classpath are the ones it will use?

[Riven]

@Eli Delventhal

@Riven

@Eli Delventhal

The only real trick you need is if you have AssetA.jpg in bundle 1 and also in bundle 5, you need to make sure to use the one in bundle 5 as that’s more recent.

Which can be achieved by ordering the jars in the classpath.

Oh, that’s cool. I didn’t know it was able to do that. I assume the lastmost jars in the classpath are the ones it will use?

The first.