NotSerializableException (question for pals from Apple)
Michael Hall
mik3hall at gmail.com
Fri Nov 11 02:45:17 PST 2011
On Nov 11, 2011, at 5:18 AM, Alexander Potochkin wrote:
> Hello Mike
>> On Nov 10, 2011, at 10:33 AM, Alexander Potochkin wrote:
>>
>>> Hello
>>>
>>> I am working on the following bug:
>>> http://java.net/jira/browse/MACOSX_PORT-543
>>>
>>> I checked that the provided code fails in the official JDK 6 from Apple,
>>> does it mean that Aqua ui delegates are not designed to be serializable?
>> We never focused on making the Aqua UI serializable, outside of what was required by the JCK or customer complaints. I wouldn't surprised if this is broken, but it was not a conscious design decision.
>
> I see
If I'm understanding this correctly is there any serializable L&F other than metal? I didn't think so.
I did come up something for Aqua at one point for my own application. It relied on my own Object input/output streams. It tried to substitute constructable instances of the classes that couldn't be serializable. Basically on the deserialize if it encountered one of these blueprint substitutes it would try to construct a new instance according to it's specs.
It got into having to bypass access restrictions at times to access object state to properly construct new instances with correctly set fields. Sometimes of non-public api Apple classes.
it was a little difficult to come up with correct substitute versions sometimes.
It was easily breakable. Change the ui a little bit and new classes became involved in serialization that I hadn't addressed.
It was also very vulnerable to breaking if any of the underlying non-public API classes changed. Very possible.
I thought if you really analyzed the Swing interfaces you could determine the proper places to do the needed substitutions that wouldn't involve getting into the tricky private API's. This could also work to make any L&F effectively serializable.
I never followed through on that though.
More information about the macosx-port-dev
mailing list