Naturalmente, a melhor pessoa para fazer esta pergunta é alguém no Comitê Executivo do JCP, não nós. No entanto, isso não me impedirá de me envolver em alguma especulação ociosa.
A resposta para todas as perguntas "por que esse recurso não foi implementado" é sempre porque os benefícios não excederam os custos.
Eric Lippert (ex-membro da equipe de C #) diz que, para que um produto tenha um recurso, esse recurso deve ser:
- pensado em primeiro lugar
- desejado
- projetado
- Especificadas
- implementado
- testado
- documentado
- enviado aos clientes
Em outras palavras, deve haver muitas coisas importantes que devem acontecer antes que qualquer novo recurso da linguagem de programação possa ser realizado. Os custos são maiores do que você pensa que são.
Na equipe de C #, cada nova solicitação de recurso começa com uma pontuação de menos 100. Em seguida, a equipe avalia os benefícios e os custos, adicionando pontos para os benefícios e subtraindo pontos para os custos. Se a pontuação não ultrapassar zero, o recurso proposto será descartado sumariamente. Em outras palavras, o novo recurso deve fornecer um benefício atraente.
Mas o Elvis Operator transformou-o em C #. Então, por que não chegou ao Java?
Apesar de suas aparentes semelhanças, Java e C # têm filosofias de linguagem significativamente diferentes. Isso é evidenciado pelo fato de que os programas corporativos Java tendem a ser grandes coleções estruturais de arquitetura. A brevidade e a expressividade da linguagem são sacrificadas no altar da cerimônia e na facilidade de codificação. Os padrões de arquitetura de software conhecidos que todos na equipe de desenvolvimento podem reconhecer são preferidos às conveniências de linguagem.
Considere esta troca do Reddit :
O operador Elvis foi proposto para todas as versões do Java desde 7 e foi rejeitado todas as vezes. Linguagens diferentes caem em pontos diferentes ao longo do espectro, de "puro" a "pragmático", e as linguagens que implementam o operador Elvis tendem a estar mais próximas do final pragmático do espectro que o Java.
Se você tem uma equipe de mais de 15 anos em Java, desenvolvendo algum tipo de sistema de processamento de back-end altamente distribuído e simultâneo, provavelmente deseja um alto grau de rigor arquitetural.
No entanto, se você tem uma equipe de nível intermediário a médio, metade dos quais migrou do Visual Basic, e você está escrevendo um aplicativo Web do ASP.NET que geralmente executa operações CRUD ... pode ser um exagero projetar um monte de AbstractFactoryFactoryclasses para abstrair o fato de que você não tem controle sobre quais colunas são anuláveis no banco de dados herdado de merda que você deve usar.
Essas profundas diferenças na filosofia da linguagem se estendem não apenas à maneira como as línguas são usadas, mas à maneira como o processo de design da linguagem é realizado. C # é uma linguagem ditadora benevolente . Para inserir um novo recurso no C #, você só precisa convencer uma pessoa: Anders Hejlsberg .
Java adota uma abordagem mais conservadora. Para inserir um novo recurso em Java, é necessário obter consenso de um consórcio de grandes fornecedores, como Oracle, IBM, HP, Fujitsu e Red Hat. Obviamente, esse processo será mais lento e apresentará uma barra mais alta para novos recursos de idioma.
A pergunta "por que o recurso x não foi implementado ..." sempre inclui implicitamente as palavras "... se é obviamente uma boa idéia?" Como demonstrei adequadamente aqui, a escolha nunca é tão simples.