Gostaria de propor esta discussão aqui no fórum, andei pensando sobre o assunto e acho que seria legal um tópico sobre isso para expandir os conhecimentos.
Quem sabe não sai uma idéia daqui direto para a JCP?
PS: Para aqueles que não tiverem interesse em participar positivamente, por favor apenas desconsiderem o tópico.
Falta uma implementação de zlib decente, pois é triste ter que usar a biblioteca não-oficial jzlib no lugar do pacote java.util.zip, que deveria prover todas as funcionalidades da popular biblioteca zlib.
Uma versão da runtime “lite”, pra facilitar a adesão pelos usuários, instalação do plugins pros browsers por exemplo, num sei se apenas tirando os @Deprecated resolveria.
Uma boa faxina ia bem! Ter uma versão mais ‘moderna’, tipo remover compatibilidade com as versões 1.1~1.3. Até pq muitas coisas escritas nessas versões não funcionam direto no 1.5~1.6.
Melhorar a manipulação de datas (ainda bem que já tem JSR para isso), especialmente no calendário gregoriano, que é usado na maior parte do mundo;
Ter formas de se trabalhar com console (uma API para isso). Se suportar consoles remoto e de diferentes tipos de terminal, melhor ainda. Seria ótimo poder conectar a um terminal ASCII e mostrar coisas com cores, etc.
Eliminação de código gordo. Seria legal também se revisassem as classes para utilização de enums (como no caso do JOptionPane) ao invés daqueles int e public static final (nem que isso gerasse métodos deprecated por algumas versões). O mesmo vale para várias classes do Swing que aceitam Vectors ao invés de Lists(JComboBox, JListBox por exemplo);
Eliminar muitas das esquizofrenias da linguagem também seria legal. Há coisas simples (como setar um tamanho de um textfield) que são muito complexas de se fazer. Digo isso especialmente para coisas que já tem uma solução comum em outros ambientes ou para coisas que a Sun já publicou artigos explicando o “Java Way” de tão recorrentes que são.
(Nada contra o DocumentModel para o Swing no caso do JTextField, mas pelo menos ter um FixedLengthDocumentModel por default na API ajudaria muita gente a não replicar o código que está no artigo do GUJ).
O wait não deveria ser sujeito a spurious wakeups. Aliás, poderia somente em situações irrecuperáveis, que não precisassemos nos preocupar (como o cancelamento da aplicação pelo SO). Da forma como é implementado hoje, essa deve ser uma preocupação constante de quem programa em multi-threads. Mesmo as novas classes de lock não corrigem esse comportamento.