As they should. I agree that this diagnostic should exist. If they have
broken code which triggers the warning, I for one have no sympathy for them.
Put another way, there's no such thing as "incidental" serializability.
Like it or not, you're taking on that contract when you extend a class
that's serializable as surely as if you put the interface on your own class.
And yes, exceptions DO often end up serialized even when they're not
directly intended to be, whether due to persistence, networking, or
whatever. It's part of the contract of Throwable, so there's no reason to
ever expect it not to work.
On 08/04/2010 10:14 AM, Neal Gafter wrote:
Unfortunately, many inner classes are only "incidentally" serializable -
that is, they are serializable because the superclass or some
implemented interface extends Serializable. A simple example would be
an inner exception class - even though most programs do not serialize
exceptions, this would trigger the proposed diagnostic.
On Wed, Aug 4, 2010 at 4:50 AM, Florian Weimer <[email protected]
<mailto:[email protected]>> wrote:
The JLS does not provide binary compatibility for compiler-generated
fields (such as reference to an outer class object from an inner class
object). This means that there is no reliable way to use such classes
in serialization even if all involved classes implement
java.io.Serializable. A mere recompilation of unchanged sources might
result in different compiler-generated names.
Would it make sense to enhance -Xlint:serial to warn about classes
which implement java.io.Serializable and contain compiler-generated
fields?
PS: This is quite different from the frequently observed issue where a
non-static inner class cannot be serialized because the outer class is
not serializable. Serialization works fine, but deserialization
silently results in invalid objects.
--
Florian Weimer <[email protected] <mailto:[email protected]>>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
--
- DML ☍
