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.
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.
[quote=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.
…[/quote]
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!
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
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) );
}
}
}
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 CICE já estaria de bom tamanho para mim;
:arrow: tuplas. Como eu sinto falta de tuplas.
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.
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/).
Eu como empresa, gastaria meu tempo e dinheiro com o J2EE!