Closed Bug 110789 Opened 23 years ago Closed 9 years ago

Java Applet not reload properly after class is recompiled

Categories

(Core Graveyard :: Plug-ins, defect, P3)

x86
All
defect

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: bugzilla.mozilla.org, Unassigned)

References

()

Details

From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011 BuildID: 2001101117 Perhaps Java JRE Related. PS: JRE 1.3.1.01 While Mozilla is running, I recompile a Java Applet. The Class file changes, and Mozilla should load a new Version. But Mozilla doesn't refresh it, I can press Refresh, Ctrl Refresh, and so on. Nothing Happens Reproducible: Always Steps to Reproduce: 1. Create any Hello World Java Applet, compile it and open it in mozilla using a html file with the <applet> tag. *** Leave the Mozilla Window displaying the Applet open *** 2. Change the Java File (ex. String from "Hello World!" to "Hello Mozilla"). 3. Recomplile the Java Applet (javac SecondApplet.java) 4. Try to relaod the Applet in the Browser. It should now display the new Version. I had no chance. Actual Results: Mozilla / JRE didn't refresh the Java Applet. Expected Results: The changed Java Applet should refresh -> mozilla should display the newest Version when I press "reload" or "Shift reload". Internet Explorer 5.0 SP2 Win2k works fine with "Shift refresh".
Reporter: Your build is old. Please try a more recent build: http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-win32-talkback.zip (as always, be sure to delete your old Mozilla directory before installing the new one) -> Networking: Cache
Assignee: asa → gordon
Component: Browser-General → Networking: Cache
QA Contact: doronr → tever
I have the same problem with 2002021108 on Win98(JRE1.4RC) and Win2000(JRE1.3.1_01) . In Edit/Preferences/Advanced/Cache: Compare Every Time It helps to restart Mozilla, but it would be nice if a Applet would be reloaded.
Confirming with 2002041707 Linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Changing summary.
Summary: Java Applet does not reload properly after change → Java Applet not reload properly after class is recompiled
This is a "me too" remark. I started working with Java recently and downloaded Sun's Java SDK v1.4.1 last week. I had Netscape v4.76 on Windows98se and it would not run the compiled Java Applet because the version number was too high. So I downloaded Mozilla (latest version). The applet would run fine the first time but after making a few changes to the applet and recompiling, Mozilla would not load in the new version and insisted on running the older version. Only by clearing both the memory and disk cache (or deleting everything in the temp directory) was I able to get it to run the newly compiled applet. BTW I also tried IE 5.01 and it did load the newly compiled applet every time. :-/ Grrrrrr. I'd rather use Mozilla but I may be forced to use IE. Hopefully this isn't a "feature" like Microsoft put into FoxPro's initial release where you had to get completely out of FoxPro in order to have it pick up the new code. That's why I dropped FoxPro.
Priority: -- → P3
Target Milestone: --- → mozilla1.3alpha
use java console and before you press reload button - press 'x' in java console and it will clear the applet cache and reload it from disk!
I am using Mozilla 1.4a 2003040105 with Java1.4.2Beta and have almost the same problem. When I recompile a jar file it is held by the mozilla cache. What seems to be happening is that the mozillia cache is unable to determine whether the jar file has changed and so doesn't down load it again. I have cleared the mozilla cache but to no avail. The _only_ way to make it let go of the jar file is to quit mozilla and restart. This is a very annoying bug when you are trying to develop an applet. I am 99% sure it is a problem with mozilla rather than the JRE.
The bug still exists in 1.5a (2003071814). Nothings ever releases an applet from cache except deleting the cache files manually from disk, which also means that applet caching as described in http://sunwww.epfl.ch/Java/jdk1.4/docs/guide/plugin/developer_guide/applet_caching.html is broken. This makes Mozilla unusable for applet development and deployment, thus I would raise severity of this bug.
-> defaults
Assignee: gordon → darin
QA Contact: tever → cacheqa
I got it to reload using the "press the x key on the java console" trick. Thanks to himba. So far so good. Mozilla 1.5 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
*** Bug 185658 has been marked as a duplicate of this bug. ***
*** Bug 238495 has been marked as a duplicate of this bug. ***
If you need a working test-case, you could get it from bug 238495; you don't have to recompile, just rename the class file and you'll see the problem.
Clearing the URL given in this bug since it now 404s. See comment 13 if you need an example.
Just re-added the example URL (added the file again, so no more 404). Hello World example added in URL.
This is still happening in Firefox 0.9.3 - linux
This is still happening with FF 1.0 and the latest Mozilla build. Using the Java Console action described above does work, but I would prefer to just be able to hold a key and click refresh.
Flags: blocking-aviary1.1?
Still happening with a FF 1.0+ build and Java 1.5.0. Worse, the workaround that was mentioned using the Java console does NOT WORK anymore. Even clearing FF's cache, clearing Java's cache, and then restarting FF does not help. Seems like I am now forever stuck with my old applet version, without any way to test my changes. Not a good thing for the Java development community.
Does this happen w/ a new profile? After clearing cache, can you see anything in the actual cache directory or via about:cache?
Flags: blocking-aviary1.1? → blocking-aviary1.1-
*** Bug 309154 has been marked as a duplicate of this bug. ***
Java caches the applet in a classloader cache. It is just in memory Appears the firefox issue is just the way the browser acts with the JVM. Seems firefox does not reload the VM plugin when it refreshes the page, which is probably ok in most cases except this. You can indeed clear the java classloader manually in the java console, but that just gets annoying. Restarting firefox also works, but that is bad when you have lots of windows/tabs open. A better option would be if I could disable the classloader cache in java, but I have yet to figure that out. It also appears you can disable the cache for standalone applications with javaplugin.classloader.cache.enabled, but there seems to be no way to do that for applets. Maybe firefox could reload the plugin when you press Ctrl-F5?
Assignee: darin → nobody
Target Milestone: mozilla1.3alpha → ---
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1 Still present
Yeah, unfortunately the bug is still present. There would have been, in a way, a solution to this problem if it is possible to start Firefox in a new process instance. But it's not possible, so we're really really stuck ......
Component: Networking: Cache → Plug-ins
This is not a bug we're going to fix as part of Firefox. It sounds like something that needs to be fixed within Java, and you should file this request with Oracle.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.