Serialised applets using the Sun Plug-in

[Thomas Hawtin]

Does anyone use serialised applets these days? Or ever did?

Everything works fine in the appletviewer, but not under the Sun
Plug-In. I have tried using both Opera 9 and Mozilla 1.7 on Solaris,
using 1.5.0_09. No joy. 1.4.2 does not appear to work with Opera. I get
a NullPointerException that appears to be caused by failing to load the
serialised file/URL as a resource. If the URL does not actually exist I
can get a FileNotFoundException instead.

The simple self-contained example thing:


import java.io.*;

class MakeSimple {
public static void main(String[] args) throws Exception {
FileOutputStream rawOut = new FileOutputStream("applet.ser");
try {
ObjectOutputStream out = new ObjectOutputStream(
new BufferedOutputStream(rawOut)
) {
};
out.writeObject(new SimpleApplet());
//out.writeObject(new java.applet.Applet());
out.flush();
} finally {
rawOut.close();
}
}
}


public class SimpleApplet extends java.applet.Applet {
}


<applet object="applet.ser" width="100" height="100"></applet>


It wouldn't surprise me if no-one used it. Swing components aren't
compatible across releases (and presumably vendors). It took me almost
two years after 1.5 was released to file the bug about Swing components,
by default, not being ables to be deserialised by untrusted code.

Tom Hawtin

 

[Andrew Thompson]

Does anyone use serialised applets these days? Or ever did?

I don't know about others, but I have to admit..
they are new to me.

...What is that actual point of serialising applets?

A quick bit of googling led me to these possible
advantages ..
- can encapsulate applet
1) binary,
2) resources,
3) state *and*
4) parameters.
- ..that's it really. (is there something I missed?)

So it seems to come down to 'encapsulation'
(If not, I'm about to stray off into irrelevance.)

The first and second of the above can be achieved
by rejarring the classes with the resources (crude,
but should work).

I cannot see the point in storing the state of
the applet (I *could* as far as the end user
goes, assuming it could save their 'current work',
but what is the advantage to the deployer?).

Encapsulating the parameters of the original applet
is a little trickier, and might involve either extending
the target applet and overiding init(), or putting it
inside another applet that supplies a custom applet
context that you can configure (by whatever means).

Thoughts?

Andrew T.

 

[Thomas Hawtin]

..What is that actual point of serialising applets?

A quick bit of googling led me to these possible
advantages ..
- can encapsulate applet
1) binary,
2) resources,
3) state *and*
4) parameters.
- ..that's it really. (is there something I missed?)

I cannot see the point in storing the state of
the applet (I *could* as far as the end user
goes, assuming it could save their 'current work',
but what is the advantage to the deployer?).

There are some reasons why that may be useful:
o It should be faster to deserialise than load setup code.
o A serialising bean builder can be used.
o You might want to manipulate the applet by hand to a particular
state. Put some values into a pretty pattern generator, for instance.

Given the apparent bug you could go and modify the applet to load a
serialised panel and go from there. However, I'm trying to find some set
of conditions under which the standard mechanism functions correctly. I
guess I need to delve in and find out why I'm getting null for the
resource.

Tom Hawtin