== Why is this an issue?

Instances of a ``++Serializable++`` class can be saved out to file and rehydrated at leisure. But that only works when all the values in the class instance are themselves ``++Serializable++`` (or ``++transient++``). Storing a non-serializable value in a ``++Serializable++`` class will prevent the serialization of that class. 


=== Noncompliant code example

[source,java]
----
interface Fruit extends Serializable {...} 
class Gooseberry implements Fruit { // Nonserializable because of Thread field 
  Thread thread; 
} 

class Bowl implements Serializable { 
  private static final long serialVersionUID = 1; 

  private Fruit fruit = new Gooseberry(); //Non-Compliant 
} 
----


=== Compliant solution

[source,java]
----
interface Fruit implements Serializable {...} 
class Gooseberry implements Fruit {...} //Serializable 

class Bowl implements Serializable { 
  private static final long serialVersionUID = 1; 

  private Fruit fruit = new Gooseberry(); //Compliant, Gooseberry is serializable 
} 
----


ifdef::env-github,rspecator-view[]
'''
== Comments And Links
(visible only on this page)

=== duplicates: S1948

=== on 25 Sep 2014, 08:57:12 Ann Campbell wrote:
\[~nicolas.peru] please read over this code example & make sure I correctly understood the problem. Not much data in the FB rule description to work from.

=== on 25 Sep 2014, 11:38:48 Nicolas Peru wrote:
\[~ann.campbell.2] Example updated, the FB rule refers to storage into fields that are Serializable.

=== on 9 Jan 2015, 14:58:24 Pierre-Yves Nicolas wrote:
I updated the code examples to reflect what I think is the intent of the FB rule (and I removed a crucial inconsistency).

=== on 9 Jan 2015, 15:10:39 Pierre-Yves Nicolas wrote:
If my understanding of this rule is correct, this rule is triggered when:

* the enclosing class implements Serializable (directly or not)
* the field is declared with a non-Serializable type
* the assignment assigns an instance of a non-Serializable type which is different from the type used in the field declaration.
Therefore, it only raises issues on assignments to fields which are themselves detected by RSPEC-1948.

As I don't see why someone would activate that rule without activating RSPEC-1948, I don't see how useful it is.

endif::env-github,rspecator-view[]