Clearing Java Cache

[Jay]

Hello all,

Does anybody know if it is possible to clear the java classloader cache
programmatically through an applet. I know that you can do it manually
by opening the Java Console and then pressing x to clear it but I was
wondering if you can do that programmatically (assuming that the applet
has rights to the filesystem on the computer and even better if it
doesn't).

And if you can't do it through the applet maybe through some other way.

The sole purpose for me trying to do this is that the applet does not
display properly when the page is refreshed or when the user leaves the
applet page and then returns, but the applet just hangs.

I have looked around and seen many responses to this problem but none
really work. My only solutions right now is to tell the users to close
all browsers and then reopen a fresh browser to view the applet OR open
the java console and then clear the cache and then refresh the page.

Both of these solutions are unaxeptable however. Too much for the users
to deal with, and if that wasn't enough although IE has the Java
Console in the tools menu as a default, Firefox doesn't and users would
have to download that as an extension.


Any help would be greatly appreciated, thank you.

..J

 

[Andrew Thompson]

Jay wrote:
.....

The sole purpose for me trying to do this is that the applet does not
display properly when the page is refreshed or when the user leaves the
applet page and then returns, but the applet just hangs.

It sounds more like the applet is broken.

What is the URL?

Andrew T.

 

[Jay]

It sounds more like the applet is broken.

I wish it was the applet's problem... that way I could fix it. But I
think it has something to do with the JVM and threads, maybe a bug...
but couldn't find anything on the Java bug logs. Trying to find a
workaround until I determine what the real problem is.

Oh and when the page get's refreshed this is the exception that gets
thrown:

java.lang.NullPointerException
at sun.awt.SunToolkit.postEvent(Unknown Source)
at sun.awt.windows.WComponentPeer.postEvent(Unknown Source)
at sun.awt.windows.WToolkit.eventLoop(Native Method)
at sun.awt.windows.WToolkit.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

..J

 

[Jay]

I found the following 2 bug reports that seem to fit my scenario:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4339842
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4422997

But both of them do not present a workaround

Any ideas...
..J

 

[Andrew Thompson]

I wish it was the applet's problem...

(from earlier)
What is the URL?

Andrew T.

 

[Julian Treadwell]

I found the following 2 bug reports that seem to fit my scenario:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4339842
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4422997

But both of them do not present a workaround

Any ideas...
.J

It said there is no workaround, but it did tell you how to fix the
problem, i.e.:

Evaluation:

The problem is that the applet is caching a JPanel component in the
static field. After the applet is reloading, the corresponding Swing
toolkit threads are different, so the cached Swing component no longer
behave properly. The fix is to NOT cache the Swing component. This is a
user error.

 

[Andrew Thompson]

Jay wrote: ... ....
The problem is that the applet is caching a JPanel component in the
static field. .... The fix is to NOT cache the Swing component.

I agree that this sounds like the problem & fix
with this applet. Does the applet declare any
GUI components as static?

Andrew T.

 

[Jay]

The problem is that the applet is caching a JPanel component in the

static field. After the applet is reloading, the corresponding Swing
toolkit threads are different, so the cached Swing component no longer
behave properly. The fix is to NOT cache the Swing component.

Ok... thank you for pointing that out. So i guess the right question is
how would i go about NOT caching the Swing component?

This is a user error.

Is that saying that the error is really on the client side?

..J

 

[Andrew Thompson]

Jay wrote:
....

how would i go about NOT caching the Swing component?

Do you declare any variables as 'static'? e.g.

JPanel mainPanel;
static JPanel buttonPanel;

...the 'buttonPanel' is declared as 'static'.

Andrew T.

 

[Jay]

I agree that this sounds like the problem & fix

with this applet. Does the applet declare any
GUI components as static?

Yes it does. But I don't see why that would be the problem, since when
is having static GUI components become a bad thing? Or am I completely
missing something trivial here?

 

[Jay]

how would i go about NOT caching the Swing component?

Do you declare any variables as 'static'? e.g.

JPanel mainPanel;
static JPanel buttonPanel;

..the 'buttonPanel' is declared as 'static'.

Yes. So should I go and change all my static GUI variables to non
static?

 

[Andrew Thompson]

Yes it does. But I don't see why that would be the problem,

The explanation on the bug report explains, but..

... since when
is having static GUI components become a bad thing?

When the user wants to open a second page
pointing at the same applet? (for instance)

On some browsers (with some VM's) the second page
will get a new VM, and all will be fine, on others, they
will be in the same VM and 'fighting' over the single
instance of the GUI component.

Note that the best fix is to remove the static
reference, though another strategy for solving
it is to launch the applet using web-start, and
implement the SingleInstanceService/Listener.

(If it is truly such that the end user will only
ever require a single instance - I would strongly
recommend the latter, as there is no practical
way to enfore a single instance in an applet
hosted in a web-page.)

Andrew T.

 

[Jay]

I found the following 2 bug reports that seem to fit my scenario:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4339842
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4422997

But both of them do not present a workaround

..J

 

[Andrew Thompson]

Jay wrote:
....

Yes. So should I go and change all my static GUI variables to non
static?

This thread seems to have split in two!

I have already put a technical answer on the
other branch, so I will leave this one ..hanging.

A.

 

[Jay]

Note that the best fix is to remove the static

reference, though another strategy for solving
it is to launch the applet using web-start, and
implement the SingleInstanceService/Listener.

So from what I understand my only 2 options are either remove all
static references or use web-start. Please correct me if I'm wrong...

Thanks for all your help,
..J

 

[Andrew Thompson]

So from what I understand my only 2 options are either remove all
static references ..

...to *GUI* *components*..

I guess that static 'boolean's (for example) would
not be a particular problem, though *no* *guarantees*
could be made about their (true/false) state.

...or use web-start. Please correct me if I'm wrong...

Basically. yes.

But I think we should pause all this for a moment,
step back, and ask..

Why were those GUI components declared static in
the first place? If it was *required* for the design,
- the solution is more complicated than simply
removing the static keyword
- it suggests the design might not be the best.

If it was *not* required for the design, ..remove the
static declaration and everything should be
'cool and groovy' (after flushing your own local
cache of the old classes).

Andrew T.

 

[Jhair Tocancipa Triana]

Hello all,
Does anybody know if it is possible to clear the java classloader cache
programmatically through an applet.
?

The sole purpose for me trying to do this is that the applet does not
display properly when the page is refreshed or when the user leaves the
applet page and then returns, but the applet just hangs.

I would bet this is a bug in your application.

Clearing the java classloader cache is just a fugly workaround for the
bug you are experiencing. Better you fix the bug properly. In your
code.