No significa nada en particular en referencia a java.
Un invariante de clase es simplemente una propiedad que se aplica a todas las instancias de una clase, siempre, sin importar lo que haga el otro código.
Por ejemplo,
class X {
final Y y = new Y();
}
X tiene la clase invariante de que hay una ypropiedad y nunca lo es nully tiene un valor de tipo Y.
class Counter {
private int x;
public int count() { return x++; }
}
no mantiene dos importantes invariantes
- Eso
countnunca devuelve un valor negativo debido a un posible subdesbordamiento.
- Las llamadas a
countestán aumentando estrictamente de manera monótona.
La clase modificada conserva esos dos invariantes.
class Counter {
private int x;
public synchronized int count() {
if (x == Integer.MAX_VALUE) { throw new IllegalStateException(); }
return x++;
}
}
pero no conserva el invariante que llama a counttener éxito siempre con normalidad (ausencia de violaciones TCB † ) porque countpodría generar una excepción o podría bloquear si un subproceso bloqueado posee el monitor del contador.
Cada idioma con clases facilita el mantenimiento de algunas invariantes de clase pero no de otras. Java no es una excepción:
- Las clases de Java tienen o no tienen propiedades y métodos consistentemente, por lo que las invariantes de interfaz son fáciles de mantener.
- Las clases de Java pueden proteger sus
private campos, por lo que los invariantes que dependen de datos privados son fáciles de mantener.
- Las clases de Java pueden ser finales, por lo que se pueden mantener invariantes que se basan en que no hay código que viole una invariante al crear una subclase maliciosa.
- Java permite que los
nullvalores se cuelen de muchas formas, por lo que es difícil mantener invariantes "tiene un valor real".
- Java tiene subprocesos, lo que significa que las clases que no se sincronizan tienen problemas para mantener invariantes que dependen de operaciones secuenciales en un subproceso que ocurren juntas.
- Java tiene excepciones que facilitan el mantenimiento de invariantes como "devuelve un resultado con la propiedad p o no devuelve ningún resultado", pero es más difícil mantener invariantes como "siempre devuelve un resultado".
† - Una externalidad o violación de TCB es un evento que un diseñador de sistemas asume con optimismo que no sucederá.
Por lo general, confiamos en que el hardware básico funciona como se anuncia cuando hablamos de las propiedades de los lenguajes de alto nivel construidos sobre ellos, y nuestros argumentos que sostienen los invariantes no tienen en cuenta la posibilidad de:
- Un programador que utiliza enlaces de depuración para alterar las variables locales cuando un programa se ejecuta de formas que el código no puede.
- Sus pares no usan la reflexión con
setAccessiblepara modificar privatelas tablas de búsqueda.
- Loki altera la física haciendo que su procesador compare incorrectamente dos números.
Para algunos sistemas, nuestro TCB puede incluir solo partes del sistema, por lo que es posible que no asumamos que
- Un administrador o un demonio privilegiado no matará nuestro proceso JVM,
pero podríamos asumir que
- Podemos controlar a un sistema de archivos transaccional confiable.
Cuanto más alto es un sistema, más grande es normalmente su TCB, pero cuanto menos fiables son las cosas que puede obtener de su TCB, es más probable que se mantengan sus invariantes y más fiable será su sistema a largo plazo.