Many methods offer invariants, which can be any or all of the guarantees made about what the method can do, requirements about the required state of the object when the method is invoked, or guarantees about the state of the object when the method completes. For instance, the %
operator, which computes the remainder of a number, provides the invariant that
0 <= abs(a % b) < = abs(b), for all integers a, b where b != 0
Many classes also offer invariants, which are guarantees made about the state of their objects' fields upon the completion of all any of their methods. For instance, classes whose member fields may not be modified once they have assumed a value are called immutable classes. An important consequence of immutability is that the invariants of instances of these classes are preserved throughout their lifetimes.
...
To prevent misuse, classes with invariants on which other code depends should be declared final. Furthermore, immutable classes must be declared final.
Superclasses Some superclasses must permit extension by trusted subclasses while simultaneously preventing extension by untrusted code. Declaring such superclasses to be final is infeasible because it would prevent the required extension by trusted code. Such problems require careful design for inheritance.
...
For non-final classes, the method that performs the security manager check must be invoked as an argument to a private constructor to ensure that the security check is performed before any superclass's constructor can exit. When the parent class has members that are declared private or are otherwise inaccessible to the attacker, the attacker must use reflection to exploit those members of the parent class. Declaring the parent class or its methods final prohibits this level of accessFor an example of this technique, see rule OBJ11-J. Be wary of letting constructors throw exceptions.
A method that receives an untrusted, nonfinal input argument must beware that other methods or threads might concurrently modify the input object. Some methods attempt to prevent modification by making a local copy of the input object. This is insufficient because a shallow copy of an object can still allow it to refer to mutable subobjects, that can be modified by other methods or threads. Some methods go further and perform a deep copy of the input object. Although this mitigates the problem of modifiable subobjects, the method could still receive as an argument a mutable object that extends the input object class and provides inadequate copy functionality.
...
Code in privileged blocks should be as simple as possible, both to improve reliability and to ease simplify security audits. Invocation of overridable methods permits modification of the code that is executed in the privileged context without modification of previously audited classes. Furthermore, calling overridable methods disperses the code over multiple classes, making it harder to determine which code must be audited. Malicious subclasses cannot directly exploit this issue because privileges are dropped as soon as unprivileged code is executed. Nevertheless, maintainers of the subclasses might unintentionally violate the requirements of the base class. For example, even when the base class's overridable method is thread-safe, a subclass might provide an implementation that lacks this property, leading to security vulnerabilities.
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="9df17ae9b01d189d-82d5dd17-4d30486e-b9b78cf2-3645a730331b5554dc307b61"><ac:plain-text-body><![CDATA[ | [[API 2006 | AA. Bibliography#API 06]] | Class BigInteger | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="c15053f035e60c1a-094da07e-41724331-b6e5bd3c-6761f036689d38caeb859816"><ac:plain-text-body><![CDATA[ | [[Bloch 2008 | AA. Bibliography#Bloch 08]] | Item 1. Consider static factory methods instead of constructors | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="2c72110c5d0c70d3-bf039c5b-45014fd8-9cc3ae2c-1f3143914bd43899b0c26237"><ac:plain-text-body><![CDATA[ | [[Gong 2003 | AA. Bibliography#Gong 03]] | Chapter 6, Enforcing Security Policy | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="84faf8fce19596f0-7b35528f-4ecf4308-86f08566-0d37b14dd5dd2086eeaf5b71"><ac:plain-text-body><![CDATA[ | [[Lai 2008 | AA. Bibliography#Lai 08]] | Java Insecurity, Accounting for Subtleties That Can Compromise Code | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="a014f608dd482ac0-3864d7d7-4161439a-b2d9909b-cd411f5f92b33f1cde10913d"><ac:plain-text-body><![CDATA[ | [[McGraw 1999 | AA. Bibliography#McGraw 99]] | Chapter Seven, Rule 3. Make everything final, unless there's a good reason not to | ]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="aebf5e7849a63f9d-009b895e-45044ef8-aa289e61-cf57c7ff700a70de373a6fd0"><ac:plain-text-body><![CDATA[ | [[Ware 2008 | AA. Bibliography#Ware 08]] | ]]></ac:plain-text-body></ac:structured-macro> |
...