Comportamiento indefinido en Java

Estaba leyendo esta pregunta en SO, que analiza algunos comportamientos indefinidos comunes en C ++, y me preguntaba: ¿Java también tiene un comportamiento indefinido?

Si ese es el caso, ¿cuáles son algunas causas comunes de comportamiento indefinido en Java?

Si no, ¿qué características de Java lo liberan de tales comportamientos y por qué no se han implementado las últimas versiones de C y C ++ con estas propiedades?

En Java, puede considerar el comportamiento del programa sincronizado incorrectamente indefinido.

Java 7 JLS usa la palabra "indefinido" una vez, en 17.4.8. Ejecuciones y requisitos de causalidad :

^{Usamos f|dpara denotar la función dada restringiendo el dominio de fto d. Para todos xen d, f|d(x) = f(x)y para todos los que xno están d, nof|d(x) está definido ...}

La documentación de la API de Java especifica algunos casos en que los resultados no están definidos, por ejemplo, en la fecha del constructor (en desuso) (int año, int mes, int día) :

^{El resultado no está definido si un argumento dado está fuera de los límites ...}

Javadocs para el estado ExecutorService.invokeAll (Collection) :

^{Los resultados de este método no están definidos si la colección dada se modifica mientras esta operación está en progreso ...}

Se puede encontrar un tipo menos formal de comportamiento "indefinido", por ejemplo, en ConcurrentModificationException , donde los documentos API utilizan el término "mejor esfuerzo":

^{Tenga en cuenta que el comportamiento a prueba de fallas no puede garantizarse ya que, en términos generales, es imposible hacer garantías duras en presencia de modificaciones concurrentes no sincronizadas. Las operaciones a prueba de fallas se basan ConcurrentModificationExceptionen el mejor esfuerzo . Por lo tanto, sería un error escribir un programa que dependiera de esta excepción para su corrección ...}

Apéndice

Uno de los comentarios de las preguntas se refiere a un artículo de Eric Lippert que proporciona una introducción útil a los temas: comportamiento definido por la implementación .

Recomiendo este artículo para el razonamiento independiente del lenguaje, aunque vale la pena tener en cuenta que el autor se dirige a C #, no a Java.

Tradicionalmente decimos que un idioma de lenguaje de programación tiene un comportamiento indefinido si el uso de ese idioma puede tener algún efecto; puede funcionar de la manera que espera o puede borrar su disco duro o bloquear su máquina. Además, el autor del compilador no tiene la obligación de advertirle sobre el comportamiento indefinido. (¡Y de hecho, hay algunos lenguajes en los que la especificación del lenguaje permite que los programas que usan modismos de "comportamiento indefinido" bloqueen el compilador!) ...

Por el contrario, un idioma que tiene un comportamiento definido por la implementación es aquel en el que el autor del compilador tiene varias opciones sobre cómo implementar la característica y debe elegir una. Como su nombre lo indica, el comportamiento definido por la implementación está al menos definido. Por ejemplo, C # permite que una implementación arroje una excepción o produzca un valor cuando una división entera se desborda, pero la implementación debe elegir una. No puede borrar su disco duro ...

¿Cuáles son algunos de los factores que llevan a un comité de diseño del lenguaje a dejar ciertas expresiones idiomáticas como comportamientos indefinidos o definidos por la implementación?

El primer factor importante es: ¿hay dos implementaciones existentes del lenguaje en el mercado que no están de acuerdo con el comportamiento de un programa en particular? ...

El siguiente factor importante es: ¿la característica presenta naturalmente muchas posibilidades diferentes para la implementación, algunas de las cuales son claramente mejores que otras? ...

Un tercer factor es: ¿ es la característica tan compleja que sería difícil o costoso especificar un desglose detallado de su comportamiento exacto? ...

Un cuarto factor es: ¿la función impone una gran carga al compilador para analizar? ...

Un quinto factor es: ¿la característica impone una gran carga en el entorno de tiempo de ejecución? ...

Un sexto factor es: ¿definir el comportamiento impide alguna optimización importante? ...

Esos son solo algunos factores que vienen a la mente; Por supuesto, hay muchos, muchos otros factores que los comités de diseño de lenguaje debaten antes de hacer una característica "implementación definida" o "indefinida".

_{Lo anterior es solo una cobertura muy breve; El artículo completo contiene explicaciones y ejemplos de los puntos mencionados en este extracto; es mucho vale la pena leer. Por ejemplo, los detalles dados para el "sexto factor" pueden dar una idea de la motivación para muchas declaraciones en el Modelo de memoria Java ( JSR 133 ), lo que ayuda a comprender por qué se permiten algunas optimizaciones, lo que lleva a un comportamiento indefinido mientras que otras están prohibidas, lo que lleva a limitaciones como suceder antes y requisitos de causalidad .}

_{Ninguno de los materiales del artículo es particularmente nuevo para mí, pero me condenaría si alguna vez lo viera presentado de una manera tan elegante, concisa y comprensible. Increíble.}

Fuera de mi cabeza, no creo que haya ningún comportamiento indefinido en Java, al menos no en el mismo sentido que en C ++.

La razón de esto es que hay una filosofía diferente detrás de Java que detrás de C ++. Un objetivo de diseño central de Java era permitir que los programas se ejecuten sin cambios en las plataformas, por lo que la especificación define todo de manera muy explícita.

En contraste, un objetivo central de diseño de C y C ++ es la eficiencia: no debe haber ninguna característica (incluida la independencia de la plataforma) que cueste el rendimiento, incluso si no las necesita. Con este fin, la especificación deliberadamente no define algunos comportamientos porque definirlos causaría un trabajo adicional en algunas plataformas y, por lo tanto, reduciría el rendimiento incluso para las personas que escriben programas específicamente para una plataforma y conocen todas sus idiosincrasias.

Incluso hay un ejemplo en el que Java se vio obligado a introducir retroactivamente una forma limitada de comportamiento indefinido por exactamente esa razón: la palabra clave estricta fp se introdujo en Java 1.2 para permitir que los cálculos de coma flotante se desviaran de seguir exactamente el estándar IEEE 754 como la especificación había exigido previamente , porque hacerlo requería trabajo adicional e hizo que todos los cálculos de punto flotante fueran más lentos en algunas CPU comunes, mientras que en realidad producía peores resultados en algunos casos.

Java se esfuerza bastante por exterminar el comportamiento indefinido, precisamente debido a las lecciones de los lenguajes anteriores. Por ejemplo, las variables de nivel de clase se inicializan automáticamente; Las variables locales no se inicializan automáticamente por razones de rendimiento, pero hay un sofisticado análisis de flujo de datos para evitar que alguien escriba un programa que pueda detectar esto. Las referencias no son punteros, por lo que no pueden existir referencias no válidas, y la desreferenciación nullcausa una excepción específica.

Por supuesto, quedan algunos comportamientos que no están completamente especificados, y puede escribir programas poco confiables si supone que sí. Por ejemplo, si itera sobre un valor normal (no ordenado) Set, el lenguaje garantiza que verá cada elemento exactamente una vez, pero no en qué orden los verá. El orden puede ser el mismo en ejecuciones sucesivas o puede cambiar; o puede permanecer igual mientras no ocurran otras asignaciones, o mientras no actualice su JDK, etc. Es casi imposible deshacerse de todos esos efectos; por ejemplo, tendrías que ordenar o aleatorizar explícitamente todas las operaciones de Colecciones, y eso simplemente no vale la pena la pequeña indefinición adicional.

Tienes que entender el "Comportamiento indefinido" y su origen.

Comportamiento indefinido significa un comportamiento que no está definido por los estándares. C / C ++ tiene demasiadas implementaciones de compilador diferentes y características adicionales. Estas características adicionales vinculaban el código al compilador. Esto se debió a que no había un desarrollo centralizado del lenguaje. Por lo tanto, algunas de las funciones avanzadas de algunos de los compiladores se convirtieron en "comportamientos indefinidos".

Mientras que en Java la especificación del lenguaje está controlada por Sun-Oracle y nadie más está tratando de hacer especificaciones y, por lo tanto, no hay comportamientos indefinidos.

Editado específicamente respondiendo la pregunta

1. Java está libre de comportamientos indefinidos porque los estándares se crearon antes que los compiladores
2. Los compiladores modernos de C / C ++ han estandarizado más / menos las implementaciones, pero las características implementadas antes de la estandarización aún permanecen etiquetadas como "comportamiento indefinido" porque ISO mantuvo la calma en estos aspectos.

Java elimina esencialmente todo el comportamiento indefinido que se encuentra en C / C ++. (Por ejemplo: desbordamiento de entero firmado, división por cero, variables no inicializadas, desreferencia de puntero nulo, desplazamiento de más de ancho de bit, doble libre, incluso "sin nueva línea al final del código fuente".) Pero Java tiene algunos comportamientos oscuros indefinidos que rara vez se encuentran con los programadores.

• Java Native Interface (JNI), una forma para que Java llame a código C o C ++. Hay muchas formas de fastidiar en JNI, como hacer que la firma de la función sea incorrecta, realizar llamadas no válidas a los servicios de JVM, corromper la memoria, asignar / liberar cosas incorrectamente y más. He cometido estos errores antes y, en general, toda la JVM se bloquea cuando un subproceso que ejecuta código JNI comete un error.

• Thread.stop(), que está en desuso. Citar:

  ¿Por qué está en Thread.stopdesuso?

  Porque es inherentemente inseguro. Al detener un subproceso, se desbloquean todos los monitores que ha bloqueado. (Los monitores se desbloquean ya que la ThreadDeathexcepción se propaga por la pila). Si alguno de los objetos previamente protegidos por estos monitores estaba en un estado inconsistente, otros subprocesos ahora pueden ver estos objetos en un estado inconsistente. Se dice que tales objetos están dañados. Cuando los hilos operan en objetos dañados, puede producirse un comportamiento arbitrario. Este comportamiento puede ser sutil y difícil de detectar, o puede ser pronunciado. A diferencia de otras excepciones no verificadas, ThreadDeathmata los hilos en silencio; por lo tanto, el usuario no tiene ninguna advertencia de que su programa puede estar dañado. La corrupción puede manifestarse en cualquier momento después de que ocurra el daño real, incluso horas o días en el futuro.

  https://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html