== Why is this an issue?

Serializing a non-``++static++`` inner class will result in an attempt at serializing the outer class as well. If the outer class is actually serializable, then the serialization will succeed but possibly write out far more data than was intended. 


Making the inner class ``++static++`` (i.e. "nested") avoids this problem, therefore inner classes should be ``++static++`` if possible. However, you should be aware that there are semantic differences between an inner class and a nested one: 

* an inner class can only be instantiated within the context of an instance of the outer class. 
* a nested (``++static++``) class can be instantiated independently of the outer class.


=== Noncompliant code example

[source,java]
----
public class Raspberry implements Serializable {
  // ...

  public class Drupelet implements Serializable {  // Noncompliant; output may be too large
    // ...
  }
}
----


=== Compliant solution

[source,java]
----
public class Raspberry implements Serializable {
  // ...

  public static class Drupelet implements Serializable {
    // ...
  }
}
----


== Resources

* https://wiki.sei.cmu.edu/confluence/x/ZTdGBQ[CERT, SER05-J.] - Do not serialize instances of inner classes


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

'''
== Implementation Specification
(visible only on this page)

=== Message

Make this inner class static.


'''
== Comments And Links
(visible only on this page)

=== on 25 Sep 2014, 09:19:10 Ann Campbell wrote:
\[~nicolas.peru] FB divides this into two rules: one for ``++Serializable++`` outer classes and one for non-serializable outer classes.


I really debated one rule or two because the problems caused are different in magnitude, but since the title and the recommendation are the same for both I combined. Let me know if you'd like me to split.

=== on 25 Sep 2014, 11:55:59 Nicolas Peru wrote:
\[~ann.campbell.2] Detection of the issue is the same : (non static inner class) the mitigation is different depending on the ``++Serializability++`` of the outer class. 


 Since one case will result in a runtime error (critical) and the other one in a (major) recommandation I tend to think they should be split with different severity (but implementation will probably be shared).

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