Additional -Xlint:serial warning

David M. Lloyd david.lloyd at redhat.com
Wed Aug 4 11:57:35 PDT 2010


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 <fweimer at bfk.de
> <mailto:fweimer at bfk.de>> 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 <fweimer at bfk.de <mailto:fweimer at bfk.de>>
>     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 ☍



More information about the compiler-dev mailing list