O que falta no java?

Falta uma faxina das boas, e adicionar suporte a tudo que precisar pra rodar Erlang na JVM.

Vejo voces daqui uns 40 anos. :mrgreen:

Infectado pelo Louds? (ou será o contrário?)

Mais ou menos - eu ainda vi Erlang primeiro :mrgreen:

bom se tivesse ponteiros como no c++

Em nome de tudo que eh mais sagrado e honesto nesse mundo, pra que caralhos vc quer ponteiros?!

Em nome de tudo que eh mais sagrado e honesto nesse mundo, pra que caralhos vc quer ponteiros?!

Pra usar com malloc e free

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.

Inté.

Em nome de tudo que eh mais sagrado e honesto nesse mundo, pra que caralhos vc quer ponteiros?!

Pra usar com malloc e free

Deve ser saudade dos Access violations…

Gostaria de ao atualizar um JDK eu baixar apenas um diff das versões e não baixar os 50mb tudo de novo…

Em nome de tudo que eh mais sagrado e honesto nesse mundo, pra que caralhos vc quer ponteiros?!

Pra usar com malloc e free

Hmmm, se Java fosse mais cagada-prone do que já é hoje, os desenvolvedores Java competentes seriam ainda mais valorizados?

goto seria legal para fazer altas manobras radicais ofuscadoras pelo código .

Inté.

KWill:

…
goto seria legal para fazer altas manobras radicais ofuscadoras pelo código .

Inté.

GoTo seria legal para se programar Java no melhor estilo Basic ou Cobol. Que saudade dos perform.

Até!

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.

cv:

Falta uma faxina das boas, e adicionar suporte a tudo que precisar pra rodar Erlang na JVM.

Vejo voces daqui uns 40 anos. :mrgreen:

Olha que caquina bonitinha:
http://www.guj.com.br/posts/list/57413.java

Acho que não tem jeito não, é pegar o que ainda presta e mudar de casa rsss!

1. 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;

2. 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.

3. 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);

4. 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).

5. 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.

Parou no 5? :mrgreen:

Na verdade, você pode ler mais aqui. :lol:

• Uma IDE que implemente herança visual rápida e direta!
• Piratear o conceito de componentes de algumas linguagens para turbinar o desenvolvimento visual.
• Ser mais leve.

A quantidade de coisas que o Java precisa melhorar é diretamente proporcional ao quadrado do número de JSRs existentes no momento rsss…

Olá

Eu continuo com a mesma opinião de 5 anos atrás: falta no Java suporte mínimo a acesso aos periféricos.

Como eu já disse antes: ao invés de gastar tempo e dinheiro com J2EE que tem poucas coisas que prestem, a Sun deveria ter resolvido os problemas que dificultam o uso de Java para aplicações triviais que imprimem uma notinha fiscal.

As melhores coisas do Java são servlets, JMS e JMX. O resto do J2EE é quase desnecessário e geralmente há outras alternativas ou soluções melhores. Se eu mandasse na Sun minhas fichas iriam todas no avanço do JMX e eu ainda colocava alguns engenheiros ajudando no Esper.

A idéia de suporte ao erlang na JVM é muito boa mas tenho dúvidas se rodando intermediado pela JVM o erlang conseguiria ser tão concorrente. Com a palavra o Mestre Louds.

[]s
Luca

Foi por isso que eu terminei o post com “vejo voces daqui uns 40 anos”. Sem rever um monte de conceitos fundamentais da JVM, nao da pra dar suporte a processos leves como se tem em Erlang - e o lance todo de pattern matching (que eu ainda nao entendo direito ate hoje) pode se tornar uma complicacao grande, tambem.

Luca:

…
Como eu já disse antes: ao invés de gastar tempo e dinheiro com J2EE que tem poucas coisas que prestem, a Sun deveria ter resolvido os problemas que dificultam o uso de Java para aplicações triviais que imprimem uma notinha fiscal.
…

E o que você acha que dá mais dinheiro para eles, vender suporte para J2EE ou arrumar problemas triviais para imprimir notinha fiscal? Eu como empresa, gastaria meu tempo e dinheiro com o J2EE!

ASOBrasil

no ultimo ebisodio do javaposse eles comentaram as top 10 coisas ( mais um pouquinho ) de lixos que deveriam nao existir na jvm vale a pena dar uma olhada

http://javaposse.com/index.php?post_id=214073

Então vá programar em C#, que tem ponteiros de verdade (embora você tenha de usar uma palavra-chave “unsafe” para usá-los), e a palavra-chave “goto” funcionando direitinho. Cruz credo!

A propósito, normalmente em C#, quando você está querendo usar “unsafe” ou ponteiros há uma maneira mais simples, melhor e mais rápida para fazer a mesma coisa. Por exemplo, 85% dos casos em que se usa ponteiros em C++ é para passar um parâmetro por referência (em C++ você usaria & = referência e não * = ponteiro, mas por as pessoas não saberem usar &, usam * desnecessariamente. Nesses casos, em C# é para usar a palavra-chave ref.

using System;

class MyClass {
	public static void Main() {
		TestClass Obj = new TestClass();
		Obj.fun();
	}
}

class TestClass {
	public unsafe void fun() {
		int [] iArray = new int[10];

		// store value in array
		for (int iIndex = 0; iIndex < 10; iIndex++) {
			iArray[iIndex] = iIndex * iIndex;
		}

		// get value from array
		fixed(int* pInt = iArray)
		testFun(pInt);
	}

	public unsafe void testFun(int* p_pInt) {

		for (int iIndex = 0; iIndex < 10; iIndex++) {
			Console.WriteLine(*(p_pInt + iIndex) );
		}
	}
}

O que falta no java ?

Acho que mais pessoas do sexo feminino programando nessa linguagem

[]´s

Eu nem vou colocar o que acho que poderia ser mais consistente na API, porque a lista seria muito longa. Além do mais, tenho a séria impressão de que é praticamente impossível manter a consistência em uma API tão grande. Não tenho muita esperança de vê-la mais simples nos próximos releases, afinal de contas, a entropia tende a aumentar… :?

Dado o projeto em que estou trabalhando atualmente, acho que as três coisas que eu mais gostaria de ver na linguagem - aquelas que toda hora você pensa “hum, isso aqui seria beeem mais fácil se tivesse isto” - são:

:arrow: Traits;

:arrow: closures (e nem estou falando de full closures, algo como <a href="http://docs.google.com/View?docid=k73_1ggr36h" data-bbcode="true">CICE</a> já estaria de bom tamanho para mim;

:arrow: tuplas. Como eu sinto falta de tuplas.

Abraços,

Giuliano

Concordo com o Giuliano Mega no que diz respeito à consistência da API. É muito complicado manter um emaranhado tão grande de classes devidamente “normalizadas”. Talvez a solução fosse a Sun montar um projeto para revisar minuciosamente toda a API (aproveitando as prováveis novas features do Javadoc), de modo a modificar coisas já desnecessárias (como o caso do Vector/List citado por ViniGodoy), além de remover os métodos Deprecated (claro que versões compatíveis com a 1.1 têm de continuar a existir).

Uma pequena coisinha que eu acho que poderia ser implementada é um compensador de path (?!).

Acho meio “inflador” ter de especificar package’s absolutos em relação ao package atual. Exemplo:

package ext.domain.host.module.resources;

public class Res {}

____________________________________
package ext.domain.host.module;

import ext.domain.host.module.resources.Res;

public class Main {}

O que acho desnecessário é eu ter de especificar todo o pacote no import, seria mais prático algo do tipo: se estou no pacote pack.sec, para importar uma classe do pacote pack.sec.tec, então eu usaria algo do tipo:

import this.tec;

Onde o this seria substituído pelo meu pacote em tempo de compilação. Espero que alguém tenha me entendido oO.

Complementando,

Uma coisa que eu to loco pra ver no Java 7 eh a reitificacao de tipos genericos.
Atualmente, por motivos de compatibilidade com as versoes mais antigas que nao tinham suporte a Generics, a parametrizacao de objetos eh feita com erasure…

Outro assunto que eu achei bem interessante sao as closures… mas esse assunto eu deixo nas maos do Neal Gafter (http://gafter.blogspot.com/).

Agora, soh nos resta acompanhar e aguardar…