StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>It doesn't mean anything in particular in reference to java.</p> <p>A class invariant is simply a property that holds for all instances of a class, always, no matter what other code does.</p> <p>For example,</p> <pre><code>class X { final Y y = new Y(); } </code></pre> <p>X has the class invariant that there is a <code>y</code> property and it is never <code>null</code> and it has a value of type <code>Y</code>.</p> <pre><code>class Counter { private int x; public int count() { return x++; } } </code></pre> <p>fails to maintain two important invariants</p> <ol> <li>That <code>count</code> never returns a negative value because of possible underflow.</li> <li>That calls to <code>count</code> are strictly monotonically increasing.</li> </ol> <p>The modified class preserves those two invariants.</p> <pre><code>class Counter { private int x; public synchronized int count() { if (x == Integer.MAX_VALUE) { throw new IllegalStateException(); } return x++; } } </code></pre> <p>but fails to preserve the invariant that calls to <code>count</code> always succeed normally (absent TCB-violations<sup>†</sup>) because <code>count</code> might throw an exception or it might block if a deadlocked thread owns the counter's monitor.</p> <p>Each language with classes make it easy to maintain some class invariants but not others. Java is no exception:</p> <ol> <li>Java classes consistently have or do not have properties and methods, so interface invariants are easy to maintain.</li> <li>Java classes can protect their <code>private</code> fields, so invariants that rely on private data are easy to maintain.</li> <li>Java classes can be final, so invariants that rely on there being no code that violates an invariant by crafting a malicious subclass can be maintained.</li> <li>Java allows <code>null</code> values to sneak in in many ways, so it is tough to maintain "has a real value" invariants.</li> <li>Java has threads which means that classes that do not synchronize have trouble maintaining invariants that rely on sequential operations in a thread happening together.</li> <li>Java has exceptions which makes it easy to maintain invariants like "returns a result with property p or returns no result" but harder to maintain invariants like "always returns a result".</li> </ol> <hr> <p>† - An <em>externality</em> or <em><a href="http://en.wikipedia.org/wiki/Trusted_computing_base" rel="noreferrer">TCB</a> violation</em> is an event which a systems designer optimistically assumes will not happen.</p> <p>Typically we just trust that the basic hardware works as advertised when talking about properties of high-level languages built on them, and our arguments that invariants hold don't take into account the possibility of:</p> <ul> <li>A programmer using debug hooks to alter local variables as a program runs in ways that code cannot.</li> <li>Your peers don't use reflection with <code>setAccessible</code> to modify <code>private</code> lookup tables.</li> <li>Loki altering physics causing your processor to incorrectly compare two numbers.</li> </ul> <p>For some systems our TCB might include only parts of the system, so we might not assume that</p> <ul> <li>An administrator or privileged daemon won't kill our JVM process,</li> </ul> <p>but we might assume that</p> <ul> <li>We can checkpoint to a reliable transactional file-system.</li> </ul> <p>The higher-level a system, the larger its TCB typically is, but the more unreliable things you can get out of your TCB, the more likely your invariants are to hold, and the more reliable your system will be in the long run.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload