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)
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".
Comment 1•23 years ago
|
||
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
Comment 2•23 years ago
|
||
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.
Comment 3•23 years ago
|
||
Confirming with 2002041707 Linux.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Comment 4•23 years ago
|
||
Changing summary.
Summary: Java Applet does not reload properly after change → Java Applet not reload properly after class is recompiled
Comment 5•22 years ago
|
||
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.
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.
Comment 8•21 years ago
|
||
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.
Comment 10•21 years ago
|
||
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
Comment 11•21 years ago
|
||
*** Bug 185658 has been marked as a duplicate of this bug. ***
Comment 12•21 years ago
|
||
*** Bug 238495 has been marked as a duplicate of this bug. ***
Comment 13•21 years ago
|
||
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.
Comment 14•21 years ago
|
||
Clearing the URL given in this bug since it now 404s. See comment 13 if you need
an example.
Reporter | ||
Comment 15•21 years ago
|
||
Just re-added the example URL (added the file again, so no more 404). Hello
World example added in URL.
Comment 16•20 years ago
|
||
This is still happening in Firefox 0.9.3 - linux
Comment 17•20 years ago
|
||
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.
Updated•20 years ago
|
Flags: blocking-aviary1.1?
Comment 18•20 years ago
|
||
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.
Comment 19•20 years ago
|
||
Does this happen w/ a new profile?
After clearing cache, can you see anything in the actual cache directory or via
about:cache?
Updated•20 years ago
|
Flags: blocking-aviary1.1? → blocking-aviary1.1-
Comment 20•19 years ago
|
||
*** Bug 309154 has been marked as a duplicate of this bug. ***
Comment 21•19 years ago
|
||
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?
Updated•19 years ago
|
Assignee: darin → nobody
Target Milestone: mozilla1.3alpha → ---
Comment 22•18 years ago
|
||
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
Comment 23•18 years ago
|
||
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 ......
Updated•9 years ago
|
Component: Networking: Cache → Plug-ins
Comment 24•9 years ago
|
||
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
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•