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)

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.

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.

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.

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.

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

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

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

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

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

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.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org