Problem:
Many developers use static objects in their applet code to persist data/objects across pages in the browser. Major problems associated with this are
1) Static variables are initialized only once when they are loaded, and never
re-initialized when a new instance of the applet is started within the
same browser process.
2) Objects that are stored in static may not be garbage collected properly,
this might result in out of memory in the browser process.
3) If the users use AWT/Swing components as static objects, applet might not
work properly when the page is refreshed or re-visited at a later point of
time in the same browser session. This is because the AWT/Swing components
in the static variables bounded to the applet thread group that have been
destroyed.
New APIs to encourage avoid static objects in applet code:
The new APIs enables the applet developer to stream data and objects and allows to retreive them within a browser session at a later point of time.
Many developers use static objects in their applet code to persist data/objects across pages in the browser. Major problems associated with this are
1) Static variables are initialized only once when they are loaded, and never
re-initialized when a new instance of the applet is started within the
same browser process.
2) Objects that are stored in static may not be garbage collected properly,
this might result in out of memory in the browser process.
3) If the users use AWT/Swing components as static objects, applet might not
work properly when the page is refreshed or re-visited at a later point of
time in the same browser session. This is because the AWT/Swing components
in the static variables bounded to the applet thread group that have been
destroyed.
New APIs to encourage avoid static objects in applet code:
The new APIs enables the applet developer to stream data and objects and allows to retreive them within a browser session at a later point of time.