Piores erros do java

Assuntos Gerais
#61

[quote=kicolobo]Um dos maiores erros do Java pra mim não tem nada a ver com a linguagem, mas sim com o compilador.

Quando Java foi lançado, o compilador deveria ter a opção de gerar um executável (exe). Parece bobaem não é mesmo?
O problema é que vi MUITA gente desistir do Java simplesmente por não saber executar uma aplicação feita na plataforma.

Se tivessem feito isto no início, acredito que a história do Java no desktop seria outra (ignorando os problemas de perfomance que realmente existiam no início mas que hoje não existem mais).[/quote]

Concordo. Um compilador para código nativo é essencial. Não entendo porque não fizeram, talvez porque a Sun queria garantir que o Java não ficaria restrito ao Windows com desenvolvedores desenvolvendo exclusivamente para ele.

#62

[quote=Thiagosc][quote=kicolobo]Um dos maiores erros do Java pra mim não tem nada a ver com a linguagem, mas sim com o compilador.

Quando Java foi lançado, o compilador deveria ter a opção de gerar um executável (exe). Parece bobaem não é mesmo?
O problema é que vi MUITA gente desistir do Java simplesmente por não saber executar uma aplicação feita na plataforma.

Se tivessem feito isto no início, acredito que a história do Java no desktop seria outra (ignorando os problemas de perfomance que realmente existiam no início mas que hoje não existem mais).[/quote]

Concordo. Um compilador para código nativo é essencial. Não entendo porque não fizeram, talvez porque a Sun queria garantir que o Java não ficaria restrito ao Windows com desenvolvedores desenvolvendo exclusivamente para ele.[/quote]

Ai que tá: eu não acho que deveria ser gerado um compilador para código nativo (porque isto ferraria o grande lance do Java que é o write once run anywhere (ou quase :slight_smile: )), mas sim um wrapper simples mesmo, como o que o launch4j gera, só pra dar startup na aplicação.

Eu não entendo como algo tão simples pode ser ignorado. Aliás, ignorado com certeza não foi, e certamente há uma boa razão para isto, mas mesmo assim continuo achando um vacilo enorme.

#63

Bom, se o Java tivesse compilador nativo, talvez não tivéssemos uma das melhores coisas que é o HotSpot. Um compilador tradicional, ele traz consigo estatísticas de como compilar o código usando uma abordagem comum à todos cenários.

O HotSpot vai compilar as classes e à medida que o código vai sendo utilizando, ele atualiza os dados em detrenimento do cenário, fazendo com que o código seja otimizado e em muitas situações, sua execução fica até mais rápida que código nativo, exatamente por esse fator.

O que acho que a Sun deveria ter feito logo de cara para resolver essa questão era um Launcher inteligente, como os que há hoje em dia … viu um Jar , deu dois cliques e executa a bagaça …simples assim.

#64

[quote=Thiagosc][quote=kicolobo]Um dos maiores erros do Java pra mim não tem nada a ver com a linguagem, mas sim com o compilador.

Quando Java foi lançado, o compilador deveria ter a opção de gerar um executável (exe). Parece bobaem não é mesmo?
O problema é que vi MUITA gente desistir do Java simplesmente por não saber executar uma aplicação feita na plataforma.

Se tivessem feito isto no início, acredito que a história do Java no desktop seria outra (ignorando os problemas de perfomance que realmente existiam no início mas que hoje não existem mais).[/quote]

Concordo. Um compilador para código nativo é essencial. Não entendo porque não fizeram, talvez porque a Sun queria garantir que o Java não ficaria restrito ao Windows com desenvolvedores desenvolvendo exclusivamente para ele.[/quote]
o legal do java é que o desenvolvedor programa para a vm e esquece tudo que esta fora dela, ou seja, como a gente sempre lida com o mesmo contexto de execução acaba tendo muito mais chances de dominar a plataforma.
não gerar código nativo é o preço que eles pagaram por seguir essa filosofia… toda filosofia tem um preço!
mas se vc parar e analisar o desenvolvimento desktop propriamente dito, o que atrapalhou mesmo o java nesse quesito foi o design complicado do swing, pois a questão do executável sempre teve várias formas de resolver.

#65

[quote=bobmoe]
o legal do java é que o desenvolvedor programa para a vm e esquece tudo que esta fora dela, ou seja, como a gente sempre lida com o mesmo contexto de execução acaba tendo muito mais chances de dominar a plataforma.
não gerar código nativo é o preço que eles pagaram por seguir essa filosofia… toda filosofia tem um preço!
mas se vc parar e analisar o desenvolvimento desktop propriamente dito, o que atrapalhou mesmo o java nesse quesito foi o design complicado do swing, pois a questão do executável sempre teve várias formas de resolver.[/quote]

Discordo com relação ao Swing ser complicado. Na realidade, acredito que seja mais as condições do momento em que Java foi introduzido do que a “complicação” do Swing que o atrasaram no desktop.

No caso, se a gente se lembrar de como era o mundo no final da década de 90 e início dos anos 2000, vamos perceber que o que domina a criação de aplicações desktop são as ferramentas visuais do tipo arrastar e soltar, como o Visual Studio (VB6 principalmente, muito mais que o Visual C++), Delphi e PowerBuilder. Java trouxe algo que para este mercado era aterrador: a ausência de um editor visual de interfaces. Havia um ou outro, é verdade, mas eram paupérrimos.

Eu sei porque eu vim do ambiente Delphi/VB. Ao olhar para o modo como se criava interfaces com Java eu ficava até arrepiado. Achava horrível e incrívelmente improdutivo. NO entanto, com o passar do tempo a coisa se inverteu no meu caso: criar aplicativos com o “arrastar e soltar” se mostrou horrendo. Porém, sou uma minoria. Acho que ESTE sim foi um fator para atraso no desenvolvimento desktop, não a “complexidade” do Swing que, se voce for olhar direito, nem complexo é. Se voce o comparar a outros toolkits vai ver que é inclusive um dos mais simples.

#66

Você saberá o que esperar com ou sem checked exceptions. Isso deve estar na documentação do método.
O que acaba acontecendo no Java, é que muitos programadores tratam a exception apenas para relança-la como uma exception de runtime ou gerar um log. Ou seja, desabilitam o tratamento. Outros, seguem sua sugestão, de simplesmente repassar o throws, o que na minha opinião é muito pior.

Quem está comprometido com o tratamento correto, irá faze-lo com ou sem checked exception. Até porque, o menor dos problemas em exception safety está em capturar a exceção em si, mas sim, em garantir que o estado do objeto continue válido, após o disparo dessa exception.

Pelo visto você nunca usou a API de SQL da sun. Como assim, exceptions checked quando não há o que fazer não atrapalham? Você nunca escreveu um try dentro do outro, só porque o seu finally tem que tratar uma exception que pode ocorrer ao fechar uma conexão? O código fica tão horrível, que já estão propondo um syntax suggar para a versão 7 do Java.

[quote=Thiagosc]Se o desenvolvedor não sabe programar as interfaces adequadamente , a culpa é dele e não da linguagem.
Checked exceptions não muda nada isso, apenas garante que o erro seja tratado.[/quote]

Acontece que o desenvolvedor não pode prever como um usuário irá usar a API, na maior parte dos casos. Se ele não pode prever, ele também não pode imaginar o que será feito, e o que não será feito.

Ainda assim, um erro com checked exception custa muito caro, pois elas tornam-se parte da interface pública a API e, uma vez declaradas, não podem ser modificadas.

Quem foi que falou em não tratar exceptions? Ou deixar o aplicativo falhar horrivelmente? Ninguém falou que o recurso de exceptions irá deixar de existir. Estamos falando apenas de checked exceptions. O que ocorre no C# é que os pontos onde você pode se recuperar, você trata as exceptions. Nos demais, você deixa que ela suba até uma camada mais alta, onde se faz log. No fundo, é o que se faz no Java, com a diferença que com checked exceptions, muitas vezes você é obrigado a gerar o log em camadas mais baixas, só para que a exception não incomode nas camadas superiores. Ou então, vc captura a exception e a encapsula numa runtime, o que é equivalente a desligar o feature.

Ou seja, você terá uma série de blocos try…catch poluindo o código, só pela obrigação de te-los, e não porque estão tomando qualquer precaução para melhoria do sistema.

Por isso discordo com você, quando você diz que checked exceptions dão “mais opção”. Se dão uma opção para quem desenvolve a API, elas tiram uma opção de quem usa a API. Ou seja, elas forçam que o programador que usa a API trata a exceção, num momento que poderia não ser o mais adequado para ele.

Se o pessoal daqui é fraquíssimo, por que continua frequentando o fórum? Para sua informação, tanto o entrevistado, quanto o entrevistador, são duas das mais importantes figuras da informática da atualidade. Eu não olharia uma entrevista com o criador da VCL e da API do C# com olhos céticos, principalmente quando o entrevistador é ninguém menos que o Bruce Eckel.

Em todo caso, apesar de estar fazendo um discurso contra as checked exceptions, devo admitir que não é um dos recursos que eu enquadraria como um dos “piores erros do java”. Só considero um recurso dispensável, mas ele não incomoda ao ponto de categoriza-lo dessa forma.

#67

[quote=kicolobo]Discordo com relação ao Swing ser complicado. Na realidade, acredito que seja mais as condições do momento em que Java foi introduzido do que a “complicação” do Swing que o atrasaram no desktop.

No caso, se a gente se lembrar de como era o mundo no final da década de 90 e início dos anos 2000, vamos perceber que o que domina a criação de aplicações desktop são as ferramentas visuais do tipo arrastar e soltar, como o Visual Studio (VB6 principalmente, muito mais que o Visual C++), Delphi e PowerBuilder. Java trouxe algo que para este mercado era aterrador: a ausência de um editor visual de interfaces. Havia um ou outro, é verdade, mas eram paupérrimos.

Eu sei porque eu vim do ambiente Delphi/VB. Ao olhar para o modo como se criava interfaces com Java eu ficava até arrepiado. Achava horrível e incrívelmente improdutivo. NO entanto, com o passar do tempo a coisa se inverteu no meu caso: criar aplicativos com o “arrastar e soltar” se mostrou horrendo. Porém, sou uma minoria. Acho que ESTE sim foi um fator para atraso no desenvolvimento desktop, não a “complexidade” do Swing que, se voce for olhar direito, nem complexo é. Se voce o comparar a outros toolkits vai ver que é inclusive um dos mais simples. [/quote]

Não sei se isso é tão incomum, kico. Comigo também foi assim. Migrei do Delphi pro Java. Tinha pavor no início, mas depois foi conhecendo o Swing profundamente, e hoje vejo que certas tarefas no Delphi eram extremamente trabalhosas. Por exemplo, no início montar uma JTable no Swing parece trabalhosíssimo. Depois, você aprende a jogar fora a porcaria do DefaultTableModel, entende como o model funciona, e percebe que montar um Table é mais do que trivial. Em poucos minutos, você tem uma tabela completamente funcional, trabalhando com suas classes de negócio, sem misturar lógica de aplicação com view. Uma maravilha.

Agora, o swing tem algumas falhas que considero meio graves. Como por exemplo, não ter a propriedade mais perguntada do fórum, que é a de definir a quantidade máxima de texto que cabe numa caixa de texto. Se não é para ter no componente, pelo menos um Document com isso pronto já seria uma mão na roda. Ter que estudar um artigo como o que temos no GUJ pode mostrar que é poderoso, mas não é nada trivial.

Também acho o esquema de foco do Swing desnecessariamente complexo e, nisso, o Delphi era realmente muito superior. Fazer o que, é o preço que se paga por ser multiplataforma.

#68

[quote=ViniGodoy]Você saberá o que esperar com ou sem checked exceptions. Isso deve estar na documentação do método.
O que acaba acontecendo no Java, é que muitos programadores tratam a exception apenas para relança-la como uma exception de runtime ou gerar um log. Ou seja, desabilitam o tratamento. Outros, seguem sua sugestão, de simplesmente repassar o throws, o que na minha opinião é muito pior. [/quote]

Isso parece programador C++ falando que basta usar “delete”. Não, não é verdade. Não basta. A documentação deve sempre dizer o que o código faz, mas isso não é o que sempre ocorre. inclusive na própria API do C#.

De qualquer forma a exception será tratada, qual é o problema? Se o desenvolvedor não sabe o que fazer com ela o problema é de quem?

[quote=ViniGodoy]
Quem está comprometido com o tratamento correto, irá faze-lo com ou sem checked exception. Até porque, o menor dos problemas em exception safety está em capturar a exceção em si, mas sim, em garantir que o estado do objeto continue válido, após o disparo dessa exception.[/quote]

O tratamento da exception é garantido em Java. Prove você que non-checked exceptions é melhor. Até agora você só disse “se isso… se aquilo… se… se…”. Isso não é problema da linguagem.

[quote=ViniGodoy]
Pelo visto você nunca usou a API de SQL da sun. Como assim, exceptions checked quando não há o que fazer não atrapalham? Você nunca escreveu um try dentro do outro, só porque o seu finally tem que tratar uma exception que pode ocorrer ao fechar uma conexão? O código fica tão horrível, que já estão propondo um syntax suggar para a versão 7 do Java.[/quote]

Isso não tem nada a ver com Exceptions. Escrever um try dentro do outro é tosqueira de linguagem derivada de Algol, assim como C++, C#, etc.

[quote=ViniGodoy]
Acontece que o desenvolvedor não pode prever como um usuário irá usar a API, na maior parte dos casos. Se ele não pode prever, ele também não pode imaginar o que será feito, e o que não será feito.[/quote]

O desenvolvedor DEVE prever como a API será usada porque esse é o trabalho dele. Se ele não consegue projetar um software então seria melhor contratar um cabelereiro ou frentista que daria na mesma.

Isso faz parte da fase de design da aplicação, seja ela antes ou incremental.

[quote=ViniGodoy]
Ainda assim, um erro com checked exception custa muito caro, pois elas tornam-se parte da interface pública a API e, uma vez declaradas, não podem ser modificadas.[/quote]

E daí? Campos privados de classes não podem ser alterados. E daí? Se o desenvolvedor estabeleceu que assim é que deve ser, quem é você para dizer o contrário?

Assim como um campo privado é privado porque alguém pensou que deveria ser privado, uma exception é uma exception porque é uma exception, oras.

[quote=ViniGodoy]

Quem foi que falou em não tratar exceptions? Ou deixar o aplicativo falhar horrivelmente? Ninguém falou que o recurso de exceptions irá deixar de existir. Estamos falando apenas de checked exceptions.[/quote]

Ó, Jesus, você precisará tratar de qualquer maneira. Por exemplo, quando um arquivo não é encontrado ou não possibilita leitura. Você precisará tratar tal erro de qualquer forma. Que diferença faz se existe um throws ou não?

Entendeu?

[quote=ViniGodoy]
Ou seja, você terá uma série de blocos try…catch poluindo o código, só pela obrigação de te-los, e não porque estão tomando qualquer precaução para melhoria do sistema.[/quote]

Não, isso é burrice do programador mesmo. Quantas pessoas aqui já lidaram com múltiplos logs? E mesmo que você fosse um completo idiota e usasse somente non-checked exceptions, que diferença isso faria?

[quote=ViniGodoy]
Por isso discordo com você, quando você diz que checked exceptions dão “mais opção”. Se dão uma opção para quem desenvolve a API, elas tiram uma opção de quem usa a API. Ou seja, elas forçam que o programador que usa a API trata a exceção, num momento que poderia não ser o mais adequado para ele.[/quote]

  1. Você precisará tratar os erros de qualquer forma. Isso é inevitável;
  2. Não tira mais do que qualquer linguagem estática que estabelece um tipo int e outro long, por exemplo. É simplesmente uma questão de deixar claro o que é o quê.

[quote=ViniGodoy]Se o pessoal daqui é fraquíssimo, por que continua frequentando o fórum? Para sua informação, tanto o entrevistado, quanto o entrevistador, são duas das mais importantes figuras da informática da atualidade. Eu não olharia uma entrevista com o criador da VCL e da API do C# com olhos céticos, principalmente quando o entrevistador é ninguém menos que o Bruce Eckel.

Em todo caso, apesar de estar fazendo um discurso contra as checked exceptions, devo admitir que não é um dos recursos que eu enquadraria como um dos “piores erros do java”. Só considero um recurso dispensável, mas ele não incomoda ao ponto de categoriza-lo dessa forma.[/quote]

Eu seria contra várias coisas, mas não porque são “desnecessárias” como você parece achar, mas por outras razões mais profundas. O pessoal aqui parece ter um fetiche por criticar o Java e elevar C# por razões estúpidas. Existem inúmeras razões porque o Java é uma merda, mas o C# tem inúmeras + 1000.

#69

Se Java é merda, então C# é merda++.

Existem inúmeras razões para se criticar o Java, como por exemplo a impossibilidade de se abstrair padrões de código (assim como C#), a gramática limitada (assim como C#), etc.

Mas assim como reificação de generics, non-checked exceptions é algo mais psicológico do que real. Quem aqui precisa consultar classes em tempo de execução para saber que tipos aceitam? E mesmo que precisassem, uma alteração dessa seria simples e não necessitaria de reificação. (Sim, eu sei como fazer)

Non-checked exceptions já existem em Java. Se quiser, use-as. Qual é o problema? Todo o preceito de Java é estabelecer uma linguagem simples e comum e assim como um desenvolvedor estabelece um campo como private, uma exception é fato. Quem reclama de checked exceptions não é diferente daqueles Python maníacos que acham que todos os campos deveriam ser public. Po que? Simplesmente porque acham que deveria ser assim, sem nenhum sentido .

#70

Não deveria alimentar o Troll, mas não aguentei…

:shock: :shock: :shock:

Quanta besteira vc fala…

#71

Engraçado… nesse caso, também é culpa do desenvolvedor, não da linguagem, não é? Curioso como para certas coisas você é rápido para excluir a responsabilidade da linguagem e culpar o desenvolvedor, e como para outras você simplesmente faz o contrário.

É pra rir?

Essa resposta prova que você não sabe do que estou falando mesmo. Depois de escrever seus primeiros SQLs, tratando exceptions corretamente, voltamos a conversar.

[quote=ViniGodoy]O desenvolvedor DEVE prever como a API será usada porque esse é o trabalho dele. Se ele não consegue projetar um software então seria melhor contratar um cabelereiro ou frentista que daria na mesma.

Isso faz parte da fase de design da aplicação, seja ela antes ou incremental.
[/quote]

Ah, mas que beleza se acertassemos sempre, não? E isso num tópico justamente criado para falar dos erros da Sun…
Na minha opinião, é melhor ter uma arquitetura que permite voltar atrás no caso de um erro, do que uma que me puna a vida inteira.

[quote=thiagosc]E daí? Campos privados de classes não podem ser alterados. E daí? Se o desenvolvedor estabeleceu que assim é que deve ser, quem é você para dizer o contrário?
Assim como um campo privado é privado porque alguém pensou que deveria ser privado, uma exception é uma exception porque é uma exception, oras.[/quote]

Isso aqui é um argumento?

[quote=ViniGodoy]Ó, Jesus, você precisará tratar de qualquer maneira. Por exemplo, quando um arquivo não é encontrado ou não possibilita leitura. Você precisará tratar tal erro de qualquer forma. Que diferença faz se existe um throws ou não?

Entendeu?[/quote]

Thiago, já expliquei porque colocar um “throws” é prejudicial. Estamos falando da interface pública de uma classe. É colocar throws de qualquer jeito que fazem atrocidades com a sua API, e levam aos erros que comentamos anteriormente.

E, para evitar os throws, temos que tratar as exceptions em camadas inferiores, onde poderia não ser o local mais adequado. Ou então, temos que repassa-las através de uma runtime, o que equivale a desligar o mecanismo.

Só estou atentando que se você observar o uso normal das exceptions, vai ver que são poucas as situações que o tratamento não recai nesses dois casos: gerar log ou repassar a exceção como runtime. Somente nessas situações, seria realmente necessário um try…catch. Mas no java, temos dezenas de blocos desses só porque a exception é verificada, e repassa-la de qualquer jeito poluiria a interface pública da nossa classe.

Faria a diferença de que repassar a exception não interferiria na interface pública da sua classe. E isso faz toda a diferença.
Agora, se você não vê diferença, sugiro que estude os conceitos básicos da OO, especialmente, o que é uma interface pública, e os problemas que uma mudança nessa interface traz para o sistema.

Quem foi que elevou o C#? Só ressaltei uma única vantagem do C# em relação ao Java. Eu poderia ter falado de qualquer outra linguagem sem checked exceptions, como o Groovy, ou o próprio C++. Só preferi o C# pq é a que tem os conceitos mais próximos do Java.

#72

Por favor, contenha seu instinto flammer. O tópico não é para ser uma guerra entre linguagens. Ninguém chamou o Java de merda, e nem estamos menosprezando o Java só porque falamos do C#, ou porque reconhecemos que a Sun cometeu alguns deslizes.

Da mesma forma, não vamos começar a xingar o C# aqui, só pq estamos num fórum de Java. O assunto do tópico é outro, que são os piores erros do Java. E esses erros não tornam a linguagem ruim. O java continua sendo uma excelente plataforma e, provavelmente, na opinião da maioria que visita esse fórum, a melhor do mercado.

#73

[quote=ViniGodoy][quote=kicolobo]Discordo com relação ao Swing ser complicado. Na realidade, acredito que seja mais as condições do momento em que Java foi introduzido do que a “complicação” do Swing que o atrasaram no desktop.

No caso, se a gente se lembrar de como era o mundo no final da década de 90 e início dos anos 2000, vamos perceber que o que domina a criação de aplicações desktop são as ferramentas visuais do tipo arrastar e soltar, como o Visual Studio (VB6 principalmente, muito mais que o Visual C++), Delphi e PowerBuilder. Java trouxe algo que para este mercado era aterrador: a ausência de um editor visual de interfaces. Havia um ou outro, é verdade, mas eram paupérrimos.

Eu sei porque eu vim do ambiente Delphi/VB. Ao olhar para o modo como se criava interfaces com Java eu ficava até arrepiado. Achava horrível e incrívelmente improdutivo. NO entanto, com o passar do tempo a coisa se inverteu no meu caso: criar aplicativos com o “arrastar e soltar” se mostrou horrendo. Porém, sou uma minoria. Acho que ESTE sim foi um fator para atraso no desenvolvimento desktop, não a “complexidade” do Swing que, se voce for olhar direito, nem complexo é. Se voce o comparar a outros toolkits vai ver que é inclusive um dos mais simples. [/quote]

Não sei se isso é tão incomum, kico. Comigo também foi assim. Migrei do Delphi pro Java. Tinha pavor no início, mas depois foi conhecendo o Swing profundamente, e hoje vejo que certas tarefas no Delphi eram extremamente trabalhosas. Por exemplo, no início montar uma JTable no Swing parece trabalhosíssimo. Depois, você aprende a jogar fora a porcaria do DefaultTableModel, entende como o model funciona, e percebe que montar um Table é mais do que trivial. Em poucos minutos, você tem uma tabela completamente funcional, trabalhando com suas classes de negócio, sem misturar lógica de aplicação com view. Uma maravilha.

Agora, o swing tem algumas falhas que considero meio graves. Como por exemplo, não ter a propriedade mais perguntada do fórum, que é a de definir a quantidade máxima de texto que cabe numa caixa de texto. Se não é para ter no componente, pelo menos um Document com isso pronto já seria uma mão na roda. Ter que estudar um artigo como o que temos no GUJ pode mostrar que é poderoso, mas não é nada trivial.

Também acho o esquema de foco do Swing desnecessariamente complexo e, nisso, o Delphi era realmente muito superior. Fazer o que, é o preço que se paga por ser multiplataforma.
[/quote]

Esta foi exatamente a minha experiência Vini (bom saber que não sou tão raro assim :slight_smile: )

Acho que o AWT foi um erro no início também. Não sei se se lembram, mas era h.o.r.r.i.v.e.l. trabalhar com ele no início.
Sim: ele deveria estar lá no início como base, mas acho que o Swing também.

Se o Swing estivesse no Java 1.0, teriamos um Java no desktop MUITO mais popular hoje, o que é uma pena
(pessoalmente, minha plataforma favorita para Desktop é o Swing apesar de todos os problemas. quando você se acostuma a ele vê que realmente é lindo como tecnologia)

#74

[quote=ViniGodoy]Sobrecarga de operadores torna o código confuso? O que te parece mais confuso?

Vector v1 = ((v2 + v3) * v1) - (4 * v4);
Vector v1 = v1.multiply(v2.add(v3)) - (v4.multiply(4));

[/quote]

hehe
É a opinião deles, não a minha. Na verdade, o mau uso do recurso é que poderia tornar confuso, mas se fosse pensar assim, muitos dos recursos do java não deveria existir.

#75

[quote=kicolobo]Ai que tá: eu não acho que deveria ser gerado um compilador para código nativo (porque isto ferraria o grande lance do Java que é o write once run anywhere (ou quase )), mas sim um wrapper simples mesmo, como o que o launch4j gera, só pra dar startup na aplicação.
[/quote]

Pelo que sei (posso estar errado) no início a proposta da linguagem C era ser multiplataforma, a idéia éra simplesmente obter o fonte, compiliar, linkeditar para o micropocessador desejado e pronto.

O problema é que muitos produtores foram adicionando recursos específicos na linguagem para aproveitar melhor os recursos dos microprocessadores e acabaram destruindo a idéia.

Talvez quem fez o Java não quiz deixar isto acontecer.

Fora isso quem aguentou um bom tempo a idéia da multiplataforma foi o COBOL, mesmo assim, hoje em dia deve haver pelo menos uma dezena de dialetos no mercado. Justamente pelos mesmos motivos: microprocessador / ambiente.

flws

#76

retroescavadeira ou retro escavadeira na nova ortográfia???

#77
#78

O que isso tem a ver com o resto do tópico?

#79

[quote=DaviPiala]API de datas é uma desgraça!

Eu fico revoltado com alguns nomes de metodos principalmente na api de servlets tipo parametros init do contexto.[/quote]

API de datas ++ a pior rs.

#80

Outra coisa, o padrão de nome de pacotes, classes e métodos é legal. Mas quando você precisa usar
System.out.println vai ver que a Sun não fez a lição de casa.

E como é que corrige agora :lol: