Coisas que odeio em Java

Que tal:

  1. Para programar para linux, Unix, HP, em ambientes onde não há um ambiente gráfico (ou o interesse em usa-lo) sem a necessidade de uma grande e complexa API?
  2. Para programar em alguns hardwares, onde não tem ambientes gráficos, mas tem um console e onde o uso de APIs externas pode ser desinteressante?
  3. Para dar aulas de java, mostrando programas “simples mas limpinhos” para alunos de java que ainda não estão preparado para as complexidades de um ambiente gráfico ou uma API externa?
  4. Para que isso seja garantido pela Sun, em todos os ambientes onde seja suportada uma VM. Assim também temos a garantia de que isso será mantido enquanto o Java existir…

E a questão aqui é simplesmente o java ter ou não esse recurso. O tópico que você mostrou é simplesmente uma prova de que tantas pessoas precisam dele que até se dignaram em fazer algumas APIs para isso!

Não seria legal então a Sun, ter uma forma 100% java de fazer isso, sem a necessidade de jar externos, garantida em todas as plataformas onde uma VM é suportada e mantida pela equipe deles?

ViniGodoy, impressão minha ou vc quer q todas as bibliotecas q vc usa estejam no JDK por padrão só pelo fato de vc usá-las?

Então, de acordo com teu raciocício, hibernate deveria vir por padrão no JDK só pra vc não ter q baixar as libs dele?

precisa de clear screen pra mostrar programinhas em java do tipo “informe x pessoas e mostre na tela” ou “informe números até seja informado uma letra e depois mostre só o maior”, por exemplo?..java não é pascal…

O q vc quer dizer com “simples mas limpinhos”?

vc quer todas as API’s do mundo no JDK?

[quote=Lich King]
vc quer todas as API’s do mundo no JDK?[/quote]
yeap :stuck_out_tongue:

[quote=Lich King]ViniGodoy, impressão minha ou vc quer q todas as bibliotecas q vc usa estejam no JDK por padrão só pelo fato de vc usá-las?

Então, de acordo com teu raciocício, hibernate deveria vir por padrão no JDK só pra vc não ter q baixar as libs dele?[/quote]

Realmente, não seria má idéia… :lol:
Aposto que se a Sun fizesse isso, você defenderia com a mesma vêemencia que vem defendendo o Java… Um framework de persistência mantido pela Sun seria legal, principalmente se ele pudesse coexistir com o Swing de maneira mais transparente que o hibernate.

Ou então, uma especificação… como no caso do JDBC. Seria mesmo muito legal um “Java Object Persistence Specification”. E o que seria do J2EE sem um conjunto de especificações desse tipo?

Ok, você não concorda com a minha afirmação do console? Tudo bem. Entretanto, isso não invalida o argumento no geral. Existem coisas que são simples em outras linguagens, mas são extremamente complexas em Java. Mas, realmente acho que o Java não deveria ficar atrás do C++, do Pascal, do Borland Dephi por causa disso.

Ok, essa foi uma clara tentativa de ridicularizar o meu argumento. Infelizmente, isso não invalida o que eu disse, tampouco defende seu ponto de vista. Você pegou 1 dos 4 itens que eu falei, mostrou programas simples (como se isso fosse um problema), e depois concluiu sem sequer dar um argumento de por que o Java não deveria ser capaz de fazer isso.

Acho que todo mundo no GUJ sabe que “Java não é Pascal”. Mas e daí? Ele também não é C++ mas tem varargs, printf… não é VB/Delphi e tem interface gráfica… Colocar funções de console também não transformará o Java no pascal.

E aliás, por que não ser capaz de fazer programas simples assim, mas que apresentem uma interface agradável (com cores, limpeza de tela, etc)? Não só aumentaria a abrangência da linguagem como também diminuiria sua curva de aprendizado. E para a linguagem no geral, acho que ter uma curva de aprendizado suave é tão importante quanto domina-la no futuro.

Sobre tipos unsigned esqueci de comentar algo.

O Java sempre fez propaganda de ser uma aplicação com amplo suporte a redes, internet, e coisas afins. Por isso senti falta dos tipos unsigned.

Mas, se usarmos o argumento do sergiotaborda (e parte dos meus também) de que isso é focado em um pensamento do futuro e que pode ser propenso a erros, ainda fica um questionamento nesse sentido.

Por que não existe um InputStream/OutputStream para isso? Quero dizer que, se desde o início a linguagem foi planejada para uso em Internet, redes e afins, não seria lógico que houvesse uma classe pelo menos preocupada em se comunicar com os servidores mais comuns do mundo naquela época, feitos em C++?

Se o seu console possui 80 linhas pq não “limpá-lo” utilizando um for de System.out.println("\n") 80 vezes?

Algumas linguagens apesar de terem funções para limpar console suas implementações são basicamente essa. Ou então utilizam alguma função especifica do SO o que seria meio dificil de implementar em Java.

Pode não ser uma solução “elegante” mas funciona.

Alguém por favor me diga como fazer grep, awk, sed, sort e uniq com a saída de um programa feito em Java que não usa o console. Se http://en.wikipedia.org/wiki/Windows_PowerShell]até a Microsoft se rendeu ao shell Java nhão ter um mínimo de suporte à CLI é ridículo.

Gambiarras para limpar o console já são feitas, o ponto é exatamente a falta de um padrão.

Quanto à especificação/biblioteca de persistência, já houveram inúmeros padrões e tentativas, o mais recente é o EJB 3.0 que pode ser integrado à uma aplicação Swing. para Java SE não existe especificação de persistência.

Ontem um colega tava reclamando que para ler um inteiro do teclado precisa fazer um Integer.parseInt, sem contar a maravilha de new StreamReader(new InputStream(new BufferedReader(new InputReaderStream(new CaceteWTF())))) só pra ler uma string…Eu achei estranho e fui procurar um modo fácil de ler um inteiro, pra minha surpresa, o menos pior que eu consegui foi um new Scanner(System.in).nextInt();

E tive que pesquisar na internet, só para ler um inteiro do teclado! Não era mais fácil um System.in.readInt(“digite”)? AH mas tem uma nova classe Console, mas que às vezes retorna null, como pra mim…

[quote=pcalcado]Alguém por favor me diga como fazer grep, awk, sed, sort e uniq com a saída de um programa feito em Java que não usa o console.
[/quote]

Você me fez lembrar de uma coisa interessante: os programas em si também deveriam ser objetos, assim teríamos comunicação transparente entre processos, onde é irrelevante se o programa/objeto é acessado por um usuário ou por outro programa, e se este programa é GUI ou shell (onde isso seria apenas perspectivas de uma mesma coisa)…

Quem sabe daqui a 20 anos surge algo assim…

Aliás, já tentaram fazer comunicação entre dois processos rodando na mesma VM?

O Java não tem qualquer suporte a isso… a não ser que você xunxe, usando RMI, que vai se comunicar por sockets no localhost.

Mas daí é usar um canhão para matar um pato.

[quote=ViniGodoy]Aliás, já tentaram fazer comunicação entre dois processos rodando na mesma VM?

O Java não tem qualquer suporte a isso… a não ser que você xunxe, usando RMI, que vai se comunicar por sockets no localhost.

Mas daí é usar um canhão para matar um pato.[/quote]

Você só consegue executar uma JVM por processo, logo não é possivel fazer comunicação entre dois processos dentro da mesma VM.

Caso você esteja falando de duas threads na mesma VM, pode usar Pipes, que Java suporta a muito, muito tempo já. Caso seja IPC, sockets são a solução mais indicada para transporte e a aplicação usa o protocolo que desejam sobre.

Java é uma linguagem pobre quando o assunto é programação concorrente, estudem Erlang e terão uma idéia de como poderia ser muito, muito mais facil.

[quote=louds]
Você só consegue executar uma JVM por processo, logo não é possivel fazer comunicação entre dois processos dentro da mesma VM.

Caso você esteja falando de duas threads na mesma VM, pode usar Pipes, que Java suporta a muito, muito tempo já. Caso seja IPC, sockets são a solução mais indicada para transporte e a aplicação usa o protocolo que desejam sobre.

Java é uma linguagem pobre quando o assunto é programação concorrente, estudem Erlang e terão uma idéia de como poderia ser muito, muito mais facil.[/quote]

Não, não estava falando de duas threads, e sim de dois processos mesmo.

Realmente, você está certo. Cada processo java tem sua VM. Me lembro que vi um artigo falando de um projeto onde gostariam que as VMs tivessem uma área compartilhada de memória e pudessem carregar uma vez só classes como String, por exemplo.

Mas, o problema básico é: não existe comunicação entre dois processos java. Pelo menos, não uma maneira direta, sem envolver sockets, compartilhamento de arquivo, etc…

[quote=ViniGodoy]
Mas, o problema básico é: não existe comunicação entre dois processos java. Pelo menos, não uma maneira direta, sem envolver sockets, compartilhamento de arquivo, etc…[/quote]

Não existe maneira portavel de implementar isso. Windows tem named pipes, sistemas posix possuem message queues e unix sockets. Cada um com características bem distintas. No final das contas, é muito melhor e mais facil usar simplesmente sockets, principalmente por tornar simples migrar de comunicação local para remota. Além disso, a diferença de performance entre sockets e primitivas de IPC é mínima.

hummm… eu imaginei que a razão fosse essa.

Filho, como se cria um tópico, tô querendo fazer Um tibia em Java, mas tô com problemas em alguns pequenos detalhes: O jogo tem q possuir a opção on e off- line, chamadas recursivas, além de um ambiente grafico em 5D (não é 3d, nem 4d, é 5!! 5!!!), melhor ainda necessita q haja interações e aliterações do usuário para com o caso em questão. Sem contar q as SDs e Uhs devem ter um efeito vermelho na tela e tb necessita q haja um botão W para q conclua-se a Conjectura projetada. Antes de mais ironias, eu ja comecei a criar esse Game. Possuo a versão 1.0 que tem a opção conglomerada de inteceptar biutres e cefalocordados além de prosocopar os ataques em um unico e concebido golpe de nomenclatura W.
Se alguém conseguir me ajudar, responda

[quote=Dublador Walawala]Filho, como se cria um tópico, tô querendo fazer Um tibia em Java, mas tô com problemas em alguns pequenos detalhes: O jogo tem q possuir a opção on e off- line, chamadas recursivas, além de um ambiente grafico em 5D (não é 3d, nem 4d, é 5!! 5!!!), melhor ainda necessita q haja interações e aliterações do usuário para com o caso em questão. Sem contar q as SDs e Uhs devem ter um efeito vermelho na tela e tb necessita q haja um botão W para q conclua-se a Conjectura projetada. Antes de mais ironias, eu ja comecei a criar esse Game. Possuo a versão 1.0 que tem a opção conglomerada de inteceptar biutres e cefalocordados além de prosocopar os ataques em um unico e concebido golpe de nomenclatura W.
Se alguém conseguir me ajudar, responda[/quote]

Cara, perdeu a graça já.

[quote=Dublador Walawala]Filho, como se cria um tópico, tô querendo fazer Um tibia em Java, mas tô com problemas em alguns pequenos detalhes: O jogo tem q possuir a opção on e off- line, chamadas recursivas, além de um ambiente grafico em 5D (não é 3d, nem 4d, é 5!! 5!!!), melhor ainda necessita q haja interações e aliterações do usuário para com o caso em questão. Sem contar q as SDs e Uhs devem ter um efeito vermelho na tela e tb necessita q haja um botão W para q conclua-se a Conjectura projetada. Antes de mais ironias, eu ja comecei a criar esse Game. Possuo a versão 1.0 que tem a opção conglomerada de inteceptar biutres e cefalocordados além de prosocopar os ataques em um unico e concebido golpe de nomenclatura W.
Se alguém conseguir me ajudar, responda[/quote]

hÁ há hà ALGUEM AQUI DORMIU COM O ARI TOLEDO ¬¬

não gosto de getters e setters. Nem conheço mta coisa do ruby, mas só nessa diferença, eu já gostei.

[quote=Dublador Walawala]Filho, como se cria um tópico, tô querendo fazer Um tibia em Java, mas tô com problemas em alguns pequenos detalhes: O jogo tem q possuir a opção on e off- line, chamadas recursivas, além de um ambiente grafico em 5D (não é 3d, nem 4d, é 5!! 5!!!), melhor ainda necessita q haja interações e aliterações do usuário para com o caso em questão. Sem contar q as SDs e Uhs devem ter um efeito vermelho na tela e tb necessita q haja um botão W para q conclua-se a Conjectura projetada. Antes de mais ironias, eu ja comecei a criar esse Game. Possuo a versão 1.0 que tem a opção conglomerada de inteceptar biutres e cefalocordados além de prosocopar os ataques em um unico e concebido golpe de nomenclatura W.
Se alguém conseguir me ajudar, responda[/quote]

tem louco pra tudo !!

era pra rir :stuck_out_tongue: