Comportamento indefinito in Java

Stavo leggendo questa domanda su SO che discute alcuni comportamenti indefiniti comuni in C ++ e mi chiedevo: Java ha anche un comportamento indefinito?

In tal caso, quali sono alcune cause comuni di comportamento indefinito in Java?

In caso contrario, quali funzionalità di Java lo rendono libero da tali comportamenti e perché le ultime versioni di C e C ++ non sono state implementate con queste proprietà?

In Java, è possibile considerare indefinito il comportamento del programma sincronizzato in modo errato.

Java 7 JLS utilizza una volta la parola "non definito", in 17.4.8. Esecuzioni e requisiti di causalità :

^{Usiamo f|dper indicare la funzione data limitando il dominio di fad . Per tutti xin d, f|d(x) = f(x)e per tutti xnon in d, nonf|d(x) è definito ...}

La documentazione dell'API Java specifica alcuni casi in cui i risultati non sono definiti - ad esempio, nella data di costruzione (obsoleta) (int year, int month, int day) :

^{Il risultato non è definito se un determinato argomento è fuori limite ...}

Javadocs per ExecutorService.invokeAll (Collection) dichiara:

^{I risultati di questo metodo non sono definiti se la raccolta data viene modificata mentre questa operazione è in corso ...}

Un tipo meno formale di comportamento "non definito" può essere trovato ad esempio in ConcurrentModificationException , dove i documenti API usano il termine "miglior sforzo":

^{Si noti che il comportamento fail-fast non può essere garantito in quanto, in generale, è impossibile fornire garanzie concrete in presenza di modifiche simultanee non sincronizzate. Le operazioni fail-fast danno ConcurrentModificationExceptionil massimo . Pertanto, sarebbe sbagliato scrivere un programma che dipendesse da questa eccezione per la sua correttezza ...}

Appendice

Uno dei commenti alle domande fa riferimento a un articolo di Eric Lippert che fornisce un'introduzione utile in argomenti: comportamento definito dall'implementazione .

Consiglio questo articolo per il ragionamento indipendente dal linguaggio, anche se vale la pena ricordare che l'autore ha come target C #, non Java.

Tradizionalmente diciamo che un linguaggio del linguaggio di programmazione ha un comportamento indefinito se l'uso di quel linguaggio può avere qualche effetto; può funzionare nel modo previsto o può cancellare il disco rigido o arrestare in modo anomalo il computer. Inoltre, l'autore del compilatore non ha l'obbligo di avvisarti del comportamento indefinito. (E in effetti, ci sono alcune lingue in cui i programmi che usano idiomi di "comportamento indefinito" sono consentiti dalle specifiche della lingua per bloccare il compilatore!) ...

Al contrario, un linguaggio che ha un comportamento definito dall'implementazione è un comportamento in cui l'autore del compilatore ha diverse scelte su come implementare la funzione e deve sceglierne una. Come suggerisce il nome, il comportamento definito dall'implementazione è almeno definito. Ad esempio, C # consente a un'implementazione di generare un'eccezione o produrre un valore quando trabocca una divisione intera, ma l'implementazione deve sceglierne una. Non è possibile cancellare il disco rigido ...

Quali sono alcuni dei fattori che portano un comitato di progettazione linguistica a lasciare determinati idiomi linguistici come comportamenti indefiniti o definiti dall'implementazione?

Il primo fattore importante è: sul mercato esistono due implementazioni esistenti che non sono d'accordo sul comportamento di un determinato programma?...

Il prossimo fattore importante è: la funzionalità presenta naturalmente molte diverse possibilità di implementazione, alcune delle quali sono chiaramente migliori di altre? ...

Un terzo fattore è: la funzionalità è così complessa che una suddivisione dettagliata del suo comportamento esatto sarebbe difficile o costosa da specificare? ...

Un quarto fattore è: la funzione comporta un onere elevato per il compilatore da analizzare? ...

Un quinto fattore è: la funzione impone un onere elevato all'ambiente di runtime? ...

Un sesto fattore è: rendere il comportamento definito preclude alcune importanti ottimizzazioni? ...

Questi sono solo alcuni dei fattori che mi vengono in mente; ci sono ovviamente molti, molti altri fattori su cui i comitati di progettazione linguistica discutono prima di creare una funzione "implementazione definita" o "non definita".

_{Sopra è solo una breve copertura; l'articolo completo contiene spiegazioni ed esempi per i punti menzionati in questo estratto; è molto più lettura vale la pena. Ad esempio, i dettagli forniti per il "sesto fattore" possono fornire uno spaccato della motivazione per molte affermazioni nel modello di memoria Java ( JSR 133 ), aiutando a capire perché alcune ottimizzazioni sono consentite, portando a comportamenti indefiniti mentre altri sono proibiti, portando a limiti come accadono prima e requisiti di causalità .}

_{Nessuno dei materiali dell'articolo è particolarmente nuovo per me, ma sarò dannato se lo avessi mai visto presentato in un modo così elegante, conciso e comprensibile. Sorprendente.}

In cima alla mia testa, non penso che ci sia un comportamento indefinito in Java, almeno non nello stesso senso di C ++.

La ragione di ciò è che c'è una filosofia diversa dietro Java rispetto a C ++. Un obiettivo progettuale di base di Java era consentire ai programmi di funzionare invariati su più piattaforme, quindi le specifiche definiscono tutto in modo molto esplicito.

Al contrario, un obiettivo di progettazione di base di C e C ++ è l'efficienza: non dovrebbero esserci caratteristiche (inclusa l'indipendenza dalla piattaforma) che costino prestazioni anche se non sono necessarie. A tal fine, la specifica non definisce deliberatamente alcuni comportamenti perché la loro definizione comporterebbe un lavoro extra su alcune piattaforme e ridurrebbe così le prestazioni anche per le persone che scrivono programmi appositamente per una piattaforma e sono consapevoli di tutte le sue idiosincrasie.

C'è anche un esempio in cui Java è stato costretto a introdurre retroattivamente una forma limitata di comportamento indefinito proprio per quel motivo: la parola chiave strictfp è stata introdotta in Java 1.2 per consentire ai calcoli in virgola mobile di deviare dal seguire esattamente lo standard IEEE 754 come precedentemente richiesto dalla specifica , poiché ciò richiedeva un lavoro extra e rendeva più lenti tutti i calcoli in virgola mobile su alcune CPU comuni, mentre in alcuni casi produceva risultati peggiori.

Java si sforza piuttosto di sterminare comportamenti indefiniti, proprio a causa delle lezioni di lingue precedenti. Ad esempio, le variabili a livello di classe vengono inizializzate automaticamente; le variabili locali non vengono inizializzate automaticamente per motivi di prestazioni, ma esiste un'analisi sofisticata del flusso di dati per impedire a chiunque di scrivere un programma in grado di rilevarlo. I riferimenti non sono puntatori, quindi non possono esistere riferimenti non validi e dereferenziazionenull provoca un'eccezione specifica.

Naturalmente rimangono alcuni comportamenti che non sono completamente specificati e puoi scrivere programmi inaffidabili se pensi che lo siano. Ad esempio, se si esegue l'iterazione su un normale (non ordinato) Set, la lingua garantisce che vedrai ogni elemento esattamente una volta, ma non nell'ordine in cui li vedrai. L'ordine potrebbe essere lo stesso per le esecuzioni successive o potrebbe cambiare; o potrebbe rimanere lo stesso fintanto che non si verificano altre allocazioni o fintanto che non aggiorni il tuo JDK, ecc. È quasi impossibile sbarazzarsi di tutti questi effetti; per esempio, dovresti ordinare o randomizzare in modo esplicito tutte le operazioni delle Collezioni, e questo semplicemente non vale la piccola non indefinita aggiunta aggiuntiva.

Devi capire il "comportamento indefinito" e la sua origine.

Comportamento indefinito significa un comportamento che non è definito dagli standard. C / C ++ ha troppe implementazioni di compilatore diverse e funzionalità aggiuntive. Queste funzionalità aggiuntive hanno legato il codice al compilatore. Questo perché non c'era uno sviluppo del linguaggio centralizzato. Quindi alcune delle funzionalità avanzate di alcuni compilatori sono diventate "comportamenti indefiniti".

Considerando che in Java la specifica del linguaggio è controllata da Sun-Oracle e non c'è nessun altro che cerca di fare specifiche e quindi nessun comportamento indefinito.

Modificato rispondendo specificamente alla domanda

1. Java è privo di comportamenti indefiniti perché gli standard sono stati creati prima dei compilatori
2. I compilatori C / C ++ moderni hanno più / meno standardizzato le implementazioni, ma le funzionalità implementate prima della standardizzazione rimangono ancora contrassegnate come "comportamento indefinito" perché ISO ha mantenuto la mamma su questi aspetti.

Java elimina essenzialmente tutto il comportamento indefinito trovato in C / C ++. (Ad esempio: overflow di numeri interi firmati, divisione per zero, variabili non inizializzate, dereference puntatore nullo, spostamento superiore alla larghezza dei bit, double-free, anche "nessuna nuova riga alla fine del codice sorgente".) Ma Java ha alcuni oscuri comportamenti indefiniti che si incontrano raramente dai programmatori.

• Java Native Interface (JNI), un modo per Java di chiamare il codice C o C ++. Esistono molti modi per rovinare JNI, come sbagliare la firma della funzione, effettuare chiamate non valide ai servizi JVM, corrompere la memoria, allocare / liberare cose in modo errato e altro ancora. Ho già commesso questi errori e in genere l'intero JVM si arresta in modo anomalo quando un thread che esegue il codice JNI commette un errore.

• Thread.stop(), che è obsoleto. Citazione:

  Perché è Thread.stopdeprecato?

  Perché è intrinsecamente pericoloso. L'arresto di un thread provoca lo sblocco di tutti i monitor che ha bloccato. (I monitor vengono sbloccati quando l' ThreadDeatheccezione si propaga nello stack.) Se uno degli oggetti precedentemente protetti da questi monitor era in uno stato incoerente, altri thread ora possono visualizzare questi oggetti in uno stato incoerente. Si dice che tali oggetti siano danneggiati. Quando i thread operano su oggetti danneggiati, può verificarsi un comportamento arbitrario. Questo comportamento può essere sottile e difficile da rilevare o può essere pronunciato. A differenza di altre eccezioni non controllate, ThreadDeathuccide i thread in silenzio; pertanto, l'utente non ha alcun avviso che il suo programma potrebbe essere danneggiato. La corruzione può manifestarsi in qualsiasi momento dopo che si è verificato il danno effettivo, anche ore o giorni in futuro.

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