A DESCRIPTION OF THE REQUEST :
Ever tried to used XMLEncoder to serialize a javabean in an unsigned applet?
This is almost impossible because it will open dozens of sockets to the applet codebase when the Introspector will lookup for BeanInfo meta classes (by appending "BeanInfo" at the end of all encountered types when marshalling). So it will last for instance 10 minutes instead of 1 second on a localhost for instance.
The effect of the problem is really similar to this one:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4668479
The problem may have been solved for ResourceBundle specifically, but with XMLEncoder you get into the same trouble.
JUSTIFICATION :
Nowadays, lots of desktop applications are ported to the web using AJAX. But mainly because of Java2D, applet do have supperior rendering capabilities at least.
Not being able to marshall a javabean in an UNSIGNED applet is VERY VERY annoying. It means you have to hardcode encoders/decoders turning fun agile developement into a maintainance nightmare.
SIGNING THE APPLET IS NOT A SOLUTION EITHER. Every time an applet will issue a certificate for some basic stuff, AJAX RIA will win over applets. Small enhancements could make that a whole different however...
The java specialist Cay Horstmann had an interresting post on this:
http://weblogs.java.net/blog/cayhorstmann/archive/2006/07/certified_insec.html
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Here is what we could expect. I propose 3 different solutions sorted by usefulness:
1) we should have a flag to disable codebase lookup in AppletClassLoader, that would be the best solution, fixing many current and future issues I believe. For instance there is no problem with the same code used in an unsigned webstart app as it won't lookup on the server (but webstart miss the browser integration).
2) other solutions might be: since the source of the problem arrises in Introspector.findExplicitBeanInfo, we should have a way to pass the IGNORE_ALL_BEANINFO flag (used by Introscpector) from XMLEncoder, or at least statically in PersistenceDelegate.
3) or at least provide the persistence delegates of MetaData in a public class. Since they were private I think this will make no regression. This will allow to make the solution I propose in the following a bit lighter.
ACTUAL -
Today, XMLEncoder will call PersistenceDelagte which will call Metadata which will call Introspector.getBeanInfo which will end up killing the network requesting inxistent BeanInfo on the applet codebase. This make marshalling very slow and network expensive.
---------- BEGIN SOURCE ----------
Here is a dummy sample:
(a real life online application called jgraphpad community edition using a workarround can also be found at http://rvalyi.blogspot.com).
You should monitor the network using the java console and see what is happening: you'll see many "network: Connecting..." to request some BeanInfo we really don't care.
import java.applet.Applet;
import java.beans.XMLEncoder;
import javax.swing.JButton;
import java.io.ByteArrayOutputStream;
public class DummyApplet extends Applet {
public void init() {
JButton fooButton=new JButton('foo');//I choosed JButton because many
//types will be encountered when it will be marshalled by Intropsector
XMLEncoder encoder = new XMLEncoder(new ByteArrayOutputStream());
encoder.writeObject(foo);
}
}
<HTML>
<HEAD>
<TITLE>DummyApplet </TITLE>
</HEAD>
<BODY>
<H1 Align="center">DummyApplet </H1> <BR>
<DIV Align="center">
<APPLET Code="DummyApplet .class" Width=50 Height=50>
</APPLET>
</DIV>
</BODY>
</HTML>
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
I found a kind of partial solution cutting 90% of the lookup but possibly introducing undiscovered side effects. Also the fix is really tricky and no lookup at all would just be too great. My solution invove subclassing PersistenceDelegate and intercept types we know their persistence delegate is a DefaultPersistenceDelagate and return a modified subclass of DefaultPersistenceDelagate that will avoid to enter MetaData.
Once you enter MetaData you are caught. Everything is sealed and it comes a time where the BeanInfo is looked up on the applet codease for your type.
The source code and sample application are in my blog at:
http://rvalyi.blogspot.com/2006/06/hacking-xmlencoder-for-unsigned-and.html