100484 - applet cannot be reload on SUNWns6 Mozilla/5.0 Netscape6/6.01

Status: CLOSED INVALID

(Core Graveyard :: Java: OJI, defect)

Description

[Brice Lecomte]

1/ include an applet in a html page
2/ display it through the browser
3/ make some changes on java code (and re-compile it !)
4/ try to see the effect on the browser, you can't

no reload or shift-reload or enter in the url really reload the applet.

bugtraqid 4502979

Comment 1

[Boris Zbarsky [:bzbarsky]]

looks like bug 51586 to me

Comment 2

[Brice Lecomte]

-rwxrwxr-x   1 blecomte other      156484 Aug 26  2000
/opt/j2sdk1_3_0/jre/plugin/sparc/javaplugin.so
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)

I really believe it is a p2, not a p3 like 51586
it is not a workaround to exit and relaunch netscape to check applet modifications !

Comment 3

[Asa Dotzler [:asa]]

->OJI

Comment 4

[edburns]

Reassign to Joe as I'm leaving the role of OJI module owner.

Comment 5

[edburns]

Ressign to Joe Chou, as I am no longer working officially on OJI.

Comment 6

[Sergey Lunegov]

This is not the mozilla bug.
I think this is bug of the java plugin because
browser is not responsible for loading of java classes.
It is the responsibility of JVM. Browser just
passes the attributes and the parameters of the applet.
There are 2 opportunities:
1) java plugin founds out the applet has been changed
	and tells to JVM to reload applet
2) browser informs the java plugin that applet has been changed	
	it requires the changin of Java Plugin Interface

I filed JPI bug in Bugtraq #4519298.
My suggestion is to mark bug bug as JPI bug.

Comment 7

[Sergey Lunegov]

This bug has 2 parts: 
1) JPI part (described in the previous comment)
2) browser part: plugin stuff on the browser side
	doesn't know whether the plugin has been loaded OR REloaded
I'm going to investigate and to fix the browser part of the bug.
Summary: this is not only JPI bug, the browser code must
be changed too.

Comment 8

[Sergey Lunegov]

I investigated problem of updated resources with Flash plugin
and figured out that Flash plugin doesn't load resource from cache:
it loads updated resource. It means if I load
document with flash resources, update those resources
and press "Reload" button in Mozilla then
updated resources will be dispalyed by Mozilla.
I discussed this bug with the
developers of Java plugin. We decided that this bug is the
problem of Java plugin not the problem of the browser.
There is no need to change interface of Java plugin and interfaces
of browser. Java plugin must understand that applet 
has been updated and must load updated applet. I suggest to
set Whiteboard status to JPI bug.

Comment 9

[Sergey Lunegov]

Bug #4519298 in bugtraq is closed. I filed the rfe #4523418 (with
the same synopsis and description)

Comment 10

[Brice Lecomte]

Am I wrong to believe that the browser should clear the java cache when it
reloads any html document  ?

as described in evaluation of the closed bugtraq 4519298:
"You can clear the classloader cache manually with the "x" option from the Java
Console.  You could also disable classloader caching with the option
javaplugin.classloader.cache.sizes=0."

Comment 11

[Sergey Lunegov]

You should NOT clear java cache before loading new html document.
The cache clearing is needed when you want to load updated java classes:
for example updated applet. 

Comment 12

[Joe Chou]

Re-assign to sep.

Comment 13

[Sergey Lunegov]

Brice, I guess I didn't understand your question.
If i understand now: you are asking --- 'If I set option 
javaplugin.classloader.cache.sizes=0 then browser should 
load updated applet (because cache doesn't exists)'.
Am I right ?
I tried to set this option in prefs.js -- it doesn't work.
I'll found out how to say browser to set cache size to 0.

Comment 14

[Brice Lecomte]

Actually, I wouldn't change the javaplugin.classloader.cache.sizes=0 because I
believe it is a global property of the browser. My question is:

Is it possible to send the "x" to the java console when the Reload (or may be
the Shift+Reload) button is preesed by user ?

IMHO, from the user point of view, "reload action means refresh the current
document because I believe it isn't well displayed." 
so it wouldn't be friendly not to reread any java classes the document might
contained.

Comment 15

[Sergey Lunegov]

To Brice: You can't send 'x' to java console during reload just because
java console maybe not displayed at the moment of reloading. I
agree that such situation is not friendly to user. But
this is responsibility of the java plugin to load updated applets.
Browser every time sends the same request to java plugin -- something
like 'createApplet'. Sending of special request (like 'clearCache' or
'createAplletAndUpdateIt') requires many changes in
interfaces of JavaPlugin and in interfaces plugin module of Mozilla.
Changes in plugin module will influence to all plugins (flash etc).
As I mentioned in some of the previous comments in case of flash plugin
everything works fine: flash plugin loads updated sources. As you read in
evaluation of
#4519298 the java plugin developers don't think this is a bug (e.g.
workaround exist) and I filed RFE (enhancement) #4523418. So I think this
is not OJI bug because browser can't send request to clear classloader cache.
I think that applet updating is actual only during applet developing so
this is not big annoyance for developer to open java console and type 'x'.

Comment 16

[Brice Lecomte]

* Ok, the developper can support to open and send an event to the java console
to clear the cache:
as far as he knows the option, and as long as such one still exist.

* About plugin, jdk, and generaly software backward compatiblity...
it is not economicaly correct to respect, I believe !
I mean, one might hope to keep being compliant in minor releases of product Z,
but when Z change to major release ;-)

So, j2se 1.4 and its plugins could include the needed modifications, no ?

Comment 17

[Sergi]

Resolve bug is invalid. Going to close it.

Comment 18

[Sergi]

Close bug.

Submitter: if you are not agree, please reopen it.

Comment 19

[Andrew A. Lyamov]

*** Bug 82288 has been marked as a duplicate of this bug. ***