2011-04-19 4 views
7

"El lenguaje Java inicializa automáticamente campos de objetos, a diferencia de las variables locales de métodos que los programadores son responsables de inicializar. Teniendo en cuenta lo que sabes sobre el análisis de flujo de datos intra e interprocesos, explica por qué los diseñadores de lengua pueden haber estas elecciones de diseño ".¿Por qué motivo específico el lenguaje Java inicializa automáticamente los campos de los objetos?

Es obvio para mí que es para evitar un error. Sin embargo, ¿qué es exactamente ese error? ¿Sería para condensar el posible flujo de control de algún método dado?

¿Podría alguien entrar en más detalles sobre esto? Realmente apreciaría la ayuda.

+1

Entonces, ¿quiere que le contestemos la pregunta de la tarea por usted? –

+0

Jaja, sí. ¿Me avergüenza? Lo siento si deliberadamente abusé de este sitio web. – VitaminYes

+3

afortunadamente, la pregunta es interesante, por lo que a nadie le importa = P – Claudiu

Respuesta

3

Es muy fácil hacer un flujo de datos dentro del procedimiento, por lo que es muy fácil verificar si un campo se ha inicializado y dar advertencias si no (se puede escribir un algoritmo decidible simplista, por ejemplo, asegurarse de que todas las ramas un if inicializa una variable, y si una rama no lo hace, falla, incluso si la rama es inalcanzable).

Es realmente difícil de hacer el flujo de datos entre procesal, por lo que es muy difícil comprobar si un campo de un objeto tiene vez ha inicializado cualquier lugar en el código (se obtiene rápidamente en territorio indecidible para cualquier aproximación razonable)

Por lo tanto, Java hace lo anterior y proporciona errores de tiempo de compilación cuando detecta variables locales no inicializadas, pero no hace lo último e inicializa los campos de un objeto a sus valores predeterminados.

1

No siempre es el caso que se inicialicen. Los objetos se pueden instanciar sin invocar a ningún constructor mediante el uso de reflexiones en combinación con la clase sun.misc.Unsafe o ObjectInputStream para acceder a estas clases con métodos nativos privados o directamente a través de JNI. Estos están destinados a la serialización/deserialización de objetos y esperan que los campos se llenen con el deserializador. En cuanto a por qué los diseñadores habrían optado por eliminar el acceso directo a estos métodos (es decir, sin reflejos), es lógico que los punteros que quedan en la memoria se puedan utilizar para ataques de destrucción de pila o de devolución a lib. Limpiar la memoria asignada para estos "automáticamente" para la mayoría de los programas reduce el riesgo de seguridad y reduce la posibilidad de errores. También tenga en cuenta que un intento de leer una variable local que no se ha inicializado da como resultado un error de compilación por el mismo motivo

Cuestiones relacionadas