java appears to cache a .class file based on its directory (?)

[Mark_Galeck]

Hello,

I have 3 files in a directory:
foo.java
foo.class
foo.html

The .java is an applet file which is compiled to the .class file,
which is then included in the .html file, via the HTML OBJECT
element. Very simple. Everything works, I run the .html file which
shows the applet.

Now, if edit the applet and recompile and run the .html file, the
browser still shows the old version of the .class file. (?)

I am using XP Pro and IE 6. I did clear the browser caches, cookies,
offline content, refreshed everything, made sure the class file is
really recompiled, still the same problem. Searched the whole disk
for a cached copy of foo.class, there is none. In fact, if I edit
the .html file, that is reflected immediately. If I rename everything
in the same directory, the problem persists.

However, if I move everything to a new directory, the
recompiled .class is shown immediately.

So, it appears somehow that Java on my system is caching its
compiled .class files somewhere I don't know about, on a per-directory
basis, and using those, instead of a freshly recompiled local .class
file.

Anybody knows what is going on here??

Thank you,

Mark

 

[Mark_Galeck]

OK, to see if that phantom file is in volatile memory, I rebooted the
computer and then, the problem disappeared. So... it's "one of these
things", kind of like the SETI "WOW" signal.

 

[Mark_Galeck]

Side note:  Java coding conventions call for class names to begin with an
Upper-case letter.

OK, got that, thank you! But, it's the next day, and... the problem
is back. I don't want to have to reboot the computer or rename
directories, every time this happens. Why is it happening - please
tell me - thank you.

Mark

 

[maaxiim]

OK, got that, thank you!  But, it's the next day, and...  the problem
is back.  I don't want to have to reboot the computer or rename
directories, every time this happens.  Why is it happening - please
tell me - thank you.

Mark

Hi Mark,

Did you try disabling applet caching ? See
http://java.sun.com/products/plugin/1.3/docs/appletcaching.html for
details.

regards

 

[Mark_Galeck]

Did you try disabling applet caching ? Seehttp://java.sun.com/products/plugin/1.3/docs/appletcaching.htmlfor
details.

Thank you maaxiim, I tried that, here is the html code:


<OBJECT
codetype="application/java"
code=Kokomo.class
width=100% height=100%
<PARAM NAME="cache_option" VALUE="No">

</OBJECT>



Still, same problem. There is this amazing effect where one and the
same applet code (.html + .class files) behaves differently depending
on which directory of Windows it is placed (behaves as the first
version compiled in that directory), but the applet of course does not
access its directory name.

 

[Mark_Galeck]

OK, so it appears that "applet caching" is happening, and I want to
prevent it. How? "cache_option" parameter with "No" value, does not
work. If I search for "applet caching", I can see this problem has
been reported several times, but not solved. So this is not just some
problem with my Windows installation.

So, how do you (everybody) debug your applets?? Please comment. You
recompile and double click on the .html file that references the
applet .class file, right? How do you prevent the old cached version
of the .class file to appear, instead of the new one.

For me, right now, every time I recompile, I have to create an
entirely new directory, never used before, move everything there, and
run, in order to get the new version of the .class file to run.

 

[Mark_Galeck]

One of the things I found was, to clear the Java cache temporary
files, in Control Panel -> Java. Does not work, still applet caching
based on directory name.

 

[John B. Matthews]

So, how do you (everybody) debug your applets?? Please comment.

0). Use an IDE that supports this.

1). Use AppletViewer's reload button.

2). Add a main that puts your applet in a (J)Frame, e.g.

<http://mindprod.com/jgloss/applet.html#SWITCHHITTER>

3). Forswear applets in favor of applications & Java Web Start.

 

[Daniel Pitts]

OK, to see if that phantom file is in volatile memory, I rebooted the
computer and then, the problem disappeared. So... it's "one of these
things", kind of like the SETI "WOW" signal.

Browsers tend to have an applet cache. One of the down-sides of
applets. I'm sure at least one regular poster here will suggest (if
they haven't already) Java Web Start instead.

 

[Andrew Thompson]

0). Use an IDE that supports this.

1). Use AppletViewer's reload button.

2). Add a main that puts your applet in a (J)Frame, e.g.

<http://mindprod.com/jgloss/applet.html#SWITCHHITTER>

3). Forswear applets in favor of applications & Java Web Start.

Great summary. One more.

- Open the java console (from that browser) and
type 'x' before refreshing the page. This is becoming
trickier, since some browsers do not seem to list
the Java console in the menus any more, and only allow
you to open it if the applet fails to load properly
(by double clicking the red 'X' located where the
applet should appear). Given the slightly tricky
nature of getting the console to appear, the methods
you outlined are all better than this one.

And I'm glad it was *you* that suggested JWS.
( Thumbs nose at D.P.

 

[John B. Matthews]

Great summary. One more.

- Open the java console (from that browser) and
type 'x' before refreshing the page. This is becoming
trickier, since some browsers do not seem to list
the Java console in the menus any more, and only allow
you to open it if the applet fails to load properly
(by double clicking the red 'X' located where the
applet should appear).

Thanks! I had despaired in this before.

For reference, it works on Mac OS X; but you have to enable the console
in the Java Preferences utility. In Safari 3, a bogus applet tag works
to get the 'X'; in Firefox 2, you have to close the applet window to see
the console.

Given the slightly tricky nature of getting the console to appear,
the methods you outlined are all better than this one.

And I'm glad it was *you* that suggested JWS.
( Thumbs nose at D.P.

I'm in late forswear...