Naturalmente, la persona migliore a porre questa domanda è qualcuno nel comitato esecutivo del JCP, non noi. Tuttavia, ciò non mi impedirà di impegnarmi in alcune speculazioni oziose.
La risposta a ogni domanda "perché questa funzionalità non è stata implementata" è sempre perché i vantaggi non hanno superato i costi.
Eric Lippert (ex membro del team C #) afferma che, affinché un prodotto abbia una funzione, tale funzione deve essere:
- pensato in primo luogo
- desiderato
- progettato
- specificato
- implementato
- testato
- documentata
- spedito ai clienti
In altre parole, ci devono essere molte cose importanti che devono accadere prima che qualsiasi nuova funzione del linguaggio di programmazione possa essere realizzata. I costi sono maggiori di quanto pensi.
Nel team C #, ogni nuova richiesta di funzionalità inizia con un punteggio di meno 100. Quindi il team valuta i vantaggi e i costi, aggiungendo punti per i vantaggi e sottraendo punti per i costi. Se il punteggio non supera lo zero, la funzione proposta viene eliminata in modo sommario. In altre parole, la nuova funzionalità deve fornire un vantaggio convincente.
Ma l' operatore Elvis è diventato C #. Quindi perché non è arrivato a Java?
Nonostante le loro apparenti somiglianze, Java e C # hanno filosofie linguistiche significativamente diverse. Ciò è dimostrato dal fatto che i programmi enterprise Java tendono ad essere grandi raccolte strutturali di architettura. La brevità e l'espressività del linguaggio sono sacrificate sull'altare della cerimonia e sulla facilità di programmazione. I modelli architetturali software ben noti che tutti nel team di sviluppo possono riconoscere sono preferiti rispetto alle comodità linguistiche.
Considera questo scambio Reddit :
L'operatore Elvis è stato proposto per ogni versione di Java dal 7 ed è stato rifiutato ogni volta. Lingue diverse ricadono in punti diversi lungo lo spettro da "puro" a "pragmatico", e le lingue che implementano l'operatore Elvis tendono ad essere più verso la fine pragmatica dello spettro rispetto a Java.
Se hai un team di oltre 15 anni di professionisti Java che scrivono un sistema di elaborazione backend altamente distribuito e concomitante di qualche tipo, probabilmente vorrai un grande rigore architettonico.
Tuttavia, se hai un team di livello medio-giovane, metà dei quali è migrato da Visual Basic e hai scritto una app Web ASP.NET che esegue principalmente operazioni CRUD ... potrebbe essere eccessivo progettare un gruppo di AbstractFactoryFactoryclassi per sottrarre il fatto che non hai alcun controllo su quali colonne sono nullable nel database legacy di merda che devi usare.
Queste profonde differenze nella filosofia linguistica si estendono non solo al modo in cui le lingue vengono utilizzate, ma anche al modo in cui viene intrapreso il processo di progettazione linguistica. C # è un linguaggio dittatore benevolo . Per inserire una nuova funzionalità in C #, devi davvero convincere una sola persona: Anders Hejlsberg .
Java adotta un approccio più conservativo. Per ottenere una nuova funzionalità in Java, deve ottenere il consenso di un consorzio di grandi fornitori come Oracle, IBM, HP, Fujitsu e Red Hat. Ovviamente, questo processo sarà più lento e presenterà una barra più alta per le nuove funzionalità linguistiche.
La domanda "perché non è stata implementata la funzione x ..." include sempre implicitamente le parole "... se è ovviamente una buona idea?" Come ho adeguatamente dimostrato qui, la scelta non è mai così semplice.