Piores erros do java

Generics sem reification* foi uma péssima idéia. O próprio gerente da implantação do Generics no Java 5.0, o Neal Gafter, gostaria de ter incluído a reification, mas isso iria quebrar a JVM (que não iria ser substancialmente modificada no Java 5.0).

• Por exemplo: poder declarar List e tal declaração usar internamente um array de int mesmo.

Muita gente pode não concordar, mas acho que exceções checadas e não checadas um saco!!! Isso é uma das seguranças que o Java tentou criar (assim como não trabalhar com ponteiro), porém essa acho que não ajudou em nada.

sobre a citada acima (Data), bem…sugiro que usem Joda Time é a única coisa que vou comentar!!! :lol:

sem duvidas a api de manipulação de dadas é a pior api feita no java q eu ja vi…

Calendar e Date!!! Mexer com datas em java é horrível.

API de datas é uma desgraça!

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

Bem uma recente foi na API de Scripting o ScriptEngineManager…

O javax.script.ScriptEngineManager serve para gerenciar os motores de script, como o próprio nome sugere, o problema é q ao registrar um engine tem q criar uma nova instancia e registrar nessa nova instancia o Engine, até ai blz, o problema é q ao perder a instancia desta classe, e se em outra altura do código vc instanciar a classe vc tem q carregar outra vez o Engine… o q é bem meio sem noção, se ela mantivesse registado todos os engines que vão sendo registrados seria muitoooo melhor… mas tb para resolver este problema é fácil, implementar uma classe q faz isto, que mantem uma instancia do ScriptEngineManager como static e ir sempre ai buscar, mas não é algo padronizado.

Até podiam ter feito um padrão parecido como nos JDBC Drivers.

Mas blz, ninguém morre por isto…

O tal do EJB 2.0/2.1 sem comentarios.

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.

Falando em Servlets… doGet, doPost… são horriveis, pior impossível!

eduveks:

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.

Falando em Servlets… doGet, doPost… são horriveis, pior impossível!

Que tal SingleThreadModel?

eduveks:

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.

Falando em Servlets… doGet, doPost… são horriveis, pior impossível!

kra eu so meio iniciante, desculpe minha ignorancia mais…pq???

Concordo sobre a manipulação de datas. Mal d+

throw null; para lançar uma NullPointerException programaticamente é bem estranho.

Tópico errado. Procure o tópico “EVGD: Códigos toscos” :lol:

maior_abandonado:

eduveks:

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.

Falando em Servlets... doGet, doPost... são horriveis, pior impossível!

kra eu so meio iniciante, desculpe minha ignorancia mais...pq???

ué... pra q tu vai querer dois métodos diferentes de inicialização para o Get e para o Post!?

veja como o netbeans resolve esta inutilidade:

protected void processRequest(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
        ...
    } 

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
        processRequest(request, response);
    } 

    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response)
    throws ServletException, IOException {
        processRequest(request, response);
    }

Se com o request.getMethod() vc pode saber se é POST ou GET... então bastava um método e ai caso precisase de diferenciar o get do post é só fazer um if com o valor do request.getMethod()...

Ou seja... doGet e doPost além de não fazer sentido, sujam o código, um tapinha na orelha do cara q inventou isto!

Acho q só em Java q inventaram este conceito de GET e POST separados, como se fosse coisas independentes...

Que tal o maior anti-pattern em java de todos os tempos? A convenção de nomenclatura JavaBeans?

Se o método tiver um nome que inicia com get<letra maiúsula> ele se torna um método mágico! set<letra maiúsula> também o deixa mágico!

O negócio é entupir suas classes de getters e setters públicos!

Questão de ponto de vista! Eu já acho que suja mais o código um if do que os dois métodos.

Em breve isso muda. Com ajuda do Michel Nascimento(Mister M).

Em breve isso muda. Com ajuda do Michel Nascimento(Mister M).

Sim, o foda são algumas interfaces do JDBC que trabalham com java.sql.Date e java.sql.Timestamp. E o suporte a algo mais novo vai depender de uma JDBC 5 no java 7 (ou talvez java 8), inclusive com suporte dos desenvolvedores de drivers JDBC.

Questão de ponto de vista! Eu já acho que suja mais o código um if do que os dois métodos.

Tou contigo, fenrir…
Quanto mais eu me aprofundo em OO, Arquitetura, boas práticas, etc, mais aversão, eu diria, tenho de IFs… argh!
hehe

Extra-oficialmente, é do interesse do EG do JDBC e do pessoal que coordena a implementação dos drivers que a JSR-310 seja suportada. Inclusive, eles têm uma idéia bem “divertida” de como suportar nossa JSR e melhorar o JDBC. Aguardem…

Java, Rails, Merb e qualquer framework de desenvolvimento de aplicações web desenvolvido por gente que tenha o mínimo de noção sobre o protocolo HTTP. GET e POST são dois métodos com semântica completamente diferente e refletir isso em uma api de desenvolvimento de aplicações web é o mínimo que se esperava.

A API de servelts tem cagadas imorais como o “init()” com parâmetros poder ser sobrescrito, mas os métodos HTTP do HttpServlet são um dos melhores exemplos de separação de responsabilidades dela.

Ah, detalhe a mais, tem gente que acha bonito sobrescrever “service()”, só que quando você sobrescreve service TODOS os métodos HTTP vão parecer implementados, então se um cliente mandar um HEAD pra você, já era, você vai mandar uma resposta completamente sem noção pra ele, ao invés de retornar um “NOT IMPLEMENTED”.

Extra-oficialmente, é do interesse do EG do JDBC e do pessoal que coordena a implementação dos drivers que a JSR-310 seja suportada. Inclusive, eles têm uma idéia bem “divertida” de como suportar nossa JSR e melhorar o JDBC. Aguardem…

Pois é, a muito tempo que eu desejo ver um gigantesco @Deprecated carimbado com letras vermelhas nestas classes infames.

[EDIT: apagado, tava falando besteira]

Cara…Se vocês tivessem que trabalhar com multimídia em Java iriam ver the dark side of Java…
Sem sombra de dúvidas a API mais tosca, zoneada, mal arquitetada e incompleta (pensando no que ela se propõe) é o JMF…Seguido do JavaSound, talvez…

É desesperador o troço…Estou pensando em migrar de tecnologia devido às limitações da bagaça…

Questão de ponto de vista! Eu já acho que suja mais o código um if do que os dois métodos.

Tou contigo, fenrir…
Quanto mais eu me aprofundo em OO, Arquitetura, boas práticas, etc, mais aversão, eu diria, tenho de IFs… argh!
hehe

eu tb acho mais organizado mais enfim… eu to malema começando com servlets e jsp… mal comecei aki…ainda tenho mto o q aprende ainda…

Extra-oficialmente, é do interesse do EG do JDBC e do pessoal que coordena a implementação dos drivers que a JSR-310 seja suportada. Inclusive, eles têm uma idéia bem “divertida” de como suportar nossa JSR e melhorar o JDBC. Aguardem…

Pois é, a muito tempo que eu desejo ver um gigantesco @Deprecated carimbado com letras vermelhas nestas classes infames.

Essa parte não vai acontecer, infelizmente…

JMF

acho que o pior erro não é nem tanto a API, mas a documentação é triste

o Java3D também já deu muitos problemas, principalmente quando se trata de placas de vídeo da ATI

eduveks:

Se com o request.getMethod() vc pode saber se é POST ou GET… então bastava um método e ai caso precisase de diferenciar o get do post é só fazer um if com o valor do request.getMethod()…

Ou seja… doGet e doPost além de não fazer sentido, sujam o código, um tapinha na orelha do cara q inventou isto!

Acho q só em Java q inventaram este conceito de GET e POST separados, como se fosse coisas independentes…

hummm… vc já ouviu falar de polimorfismo ? de sobre-escrita ? :twisted:
O objetivo de ter dois métodos é poder poder utilizar OO como deve ser e não fazer gamabiarras de ficar testando parametros.
É verdade que vc pode utilizar um método para processar os dois da mesa forma, mas isso é contra o objetivo do get e do post.
get é um funcionaldiade de leitura e post é de gravação. O fato da API de servlets facilitar as coisas para você é uma forma de vc não ter que ficar testando parametros. Já agora, existe outros métodos para PUT, STORE e outros definidos no HTTP.

moral da historia, o Servlet define esses métodos porque são os métodos definidos no HTTP. E a API ainda vai mais longe provendo ferramentas para usar servlets de forma OO.

bom acho que a já falada API de data é a top, visivelmente precaria.
Mas há outras terriveis, EJB 2 é inteiro por si só um erro, tem uns detalhes que são totalmente malucos.

Alguem aqui já falou sobre a de servlet você ter que herdar HttpServlet, ai se hora eu “chamar o super” da pau, hora sou obrigado a “chamar o super”, enfim essa foi uma puta cagada.

E properties herda HashMap?

Esses dois ultimos inclusive, se não me engano, são exemplos classicos de mau uso de herança

ddduran:

bom acho que a já falada API de data é a top, visivelmente precaria.
Mas há outras terriveis, EJB 2 é inteiro por si só um erro, tem uns detalhes que são totalmente malucos.

Alguem aqui já falou sobre a de servlet você ter que herdar HttpServlet, ai se hora eu “chamar o super” da pau, hora sou obrigado a “chamar o super”, enfim essa foi uma puta cagada.

E properties herda HashMap?

Esses dois ultimos inclusive, se não me engano, são exemplos classicos de mau uso de herança

E falando em mau uso de herança. Voltamos a java.sql.Date e java.sql.Timestamp.

Falando em HahMap, me lembrei de java.util.Hashtable e java.util.Vector. No java 1.0 foram criadas apenas como classes auxiliares para facilitar um pouco a implementação de estruturas de dados. Só na 1.2 que foram enxergar que era muito mais do que isso.

a API do POI tbm e uma porcaria…

sql.Date, sql.Time e sqlTimestamp representam 3 coisas diferentes e todas elas difernetes de util.Date.

A classe util pode ter sido gamb mas essas três não foram. util.Date contém mais dados que os necessários para o SQL
Além disso a epoca usada por um banco não tem que ser a do java. Essas classes servem para o banco entender os tipos especificos de tempo que estão em causa. Só data, só horas ou ambos. Mas elas são limitações da informação de util.Date e no fundo são “dates” então a herança ai, como em tudo, é uma forma de categroizar essas classes. dizer que elas são relacionadas a “tempo”.

Falando em HahMap, me lembrei de java.util.Hashtable e java.util.Vector. No java 1.0 foram criadas apenas como classes auxiliares para facilitar um pouco a implementação de estruturas de dados. Só na 1.2 que foram enxergar que era muito mais do que isso.

Mas isso demonstra o poder da extensão. O fato de ter sido possível incluir Vector e Hashtable na JCF demonstra que as classes estavam bem desenhadas e não mal. Não foi gambiarra, simplesmente foi menos que o necessário. Contudo, quando tiveram que integrar uma API maior, não houve problema.

sergiotaborda:

victorwss:

E falando em mau uso de herança. Voltamos a java.sql.Date e java.sql.Timestamp.

sql.Date, sql.Time e sqlTimestamp representam 3 coisas diferentes e todas elas difernetes de util.Date.

A classe util pode ter sido gamb mas essas três não foram. util.Date contém mais dados que os necessários para o SQL

A gambi está no extends. http://desciclopedia.ws/wiki/Gambi_Design_Patterns#BaseBean. Nenhuma delas deveria herdar de java.util.Date.

Bem, no javadocs de java.sql.Date diz que a herança a java.util.Date é apenas uma herança de implementação, e não deve ser considerado uma herança de tipo. Ou seja, mau uso de herança (java.sql.Date IS-NOT-A-BUT-EXTENDS java.util.Date). O mesmo vale para Timestamp.

sergiotaborda:

victorwss:

Falando em HahMap, me lembrei de java.util.Hashtable e java.util.Vector. No java 1.0 foram criadas apenas como classes auxiliares para facilitar um pouco a implementação de estruturas de dados. Só na 1.2 que foram enxergar que era muito mais do que isso.

Mas isso demonstra o poder da extensão. O fato de ter sido possível incluir Vector e Hashtable na JCF demonstra que as classes estavam bem desenhadas e não mal. Não foi gambiarra, simplesmente foi menos que o necessário. Contudo, quando tiveram que integrar uma API maior, não houve problema.

O que fode é a sincronização na maioria das vezes desnecessária, e alguns tratamentos estranhos de null. Mas o maior problema não são as classes em si, e sim as demais classes que a utilizam: code to an implementation, not to an interface.

Poxa eu gosto do POI, sempre fez o que se comprometia a fazer.
E ja me ajudou muito a fazer relatorios em XLS

mas pra fazer os malditos xls… so pra mudar a cor de uma coedula vc tenque criar um novo estilo pra ela, uma nova cor, e adicionar esta cor no estilo e este estilo na cedula depois colocar esta cedula na linha e esta linha na folha… o ruim desta api é q ela e muito desacoplada tenque criar mil objetos e colocar um dentro do outro pra fazer algo simples como pintar uma cedula mudar a borda, mudar a fonte… seria bem mais simples se ao vc fazer estas coisas vc apenas tivesse um objeto cedula com a cordenada e atributos como cor, fonte, borda, tamanho entre outros vc setasse direto no objeto…

eclipso:

Cara…Se vocês tivessem que trabalhar com multimídia em Java iriam ver the dark side of Java…
Sem sombra de dúvidas a API mais tosca, zoneada, mal arquitetada e incompleta (pensando no que ela se propõe) é o JMF…Seguido do JavaSound, talvez…

É desesperador o troço…Estou pensando em migrar de tecnologia devido às limitações da bagaça…

Eclipso, vi que você postou muita coisa sobre JMF aqui no GUJ, inclusive disponibilizou parece-me algumas soluções, estou também pensando em trabalhar INFELIZMENTE com JMF, mas ainda não me aventurei a fundo e estou com medo de perder muito tempo e me frustar. Mas em casa já irei tentar fazer alguma coisa fora do padrão e não o trivial com JMF e acho que não será nada fácil, dessa forma irei tentar disponibilizar aqui alguma coisa se eu conseguir.

Você tem MSN ou coisa do tipo?

Concordo com vocês, há muita coisa ruim no Java de se fazer, a exemplo de datas que é um pé no saco e mal formulado, a API POI da apache é meio chatinha, há ainda o temível JMF e outras coisas.

Agora desafio vocês, tentem ao menos alguma vez trabalhar com a integração Java - OpenOffice e verá o quão terrível é trabalhar com a UNO API, coisa de outro mundo (no pior dos sentidos) é no kilo do ódio.

Poxa vida…
Se

Multimidia
Som
Integração com suits office
EJB
Servlet
Data

são ruins

o que será que foi bem feito em java? (é só brincadeira heim)

eclipso:

Cara…Se vocês tivessem que trabalhar com multimídia em Java iriam ver the dark side of Java…
Sem sombra de dúvidas a API mais tosca, zoneada, mal arquitetada e incompleta (pensando no que ela se propõe) é o JMF…Seguido do JavaSound, talvez…

É desesperador o troço…Estou pensando em migrar de tecnologia devido às limitações da bagaça…

não me fale não!
No meu TCC fiquei 8 meses me matando com o JMF e fazendo processamento de vídeo em DLL’s feitas em C/C++ que eu mesmo fiz via JNI. Torci pra um dia acabar, hoje nem quero lembrar daquela bagaça! :lol:

JMF nem pra papel higiênico serve…

Sobrecarga de operadores cairia bem.

Falou o C++ orphan…

Capitão, para com isso…

É mesmo… Java deveria ter sobrecarga de operadores! :-o

… e structs também!

bicarbonato:

É mesmo… Java deveria ter sobrecarga de operadores! :-o

… e structs também!

Vi em um post a equipe do Java ser contra sobrecarga de operador por considerarem que ele atrapalha a clareza do código, já que 1+1 você não vai poder saber se é igual a 2 a menos que leia o programa inteiro.

Não vou entrar no mérito se é bom ou não, mas achei engraçado o argumento.

mas 1 é tipo primitivo… int
Eu não vou precisar ler o código!

O lance é que você pode fazer o seguinte.

String str1 = "Esta é uma ";
String str2 = “String concatenada”;

System.out.println(str1 + str2);

A classe String implementou o operador + para concatenação.

Mas se você quiser implementar esse operador na sua classe, você não pode.

Por exemplo, eu tenho um portfolio de ações A, um portfolio B e um C, todos da classe Portfolio que criei.

Se eu quiser somar a e b e subtrair as ações de c no portfolio D, tenho que fazer assim.

Portfolio d = a.add(b.sub©)); (Pode ficar pior!)

Se suportasse a sobrecarga, ficaria simples assim:

Portfolio d = a + b - c;

Sobrecarga bem usada deixa o código MUITO mais legível.

I rest my case.

pra mim foram os caras não terem dado valor em coisas pequenas e simples do dia-a-dia, como o apache commons… resultado: 10 entre 10 frameworks tem essa dependencia

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

Note que no segundo caso, fui obrigado a inverter a ordem da apresentação de algumas operações, como as multiplicações. No primeiro, seria possível buscar uma ordem que fosse matematicamente mais clara para a resolução do problema.

Sem falar, que se você quiser suportar operadores como +=, -= em classes matemáticas, você acabará com 2 assinaturas de métodos:

v1 = v1 + v2; v1 += v2; v1 = v1.add(v2); v1.addMe(v2);

Por mim, o Java também teria que rever seriamente a organização do Swing, especialmente tirando fora o legado da AWT (que foi uma das grandes falhas do Java). Seria legal também retirar a classe DefaultTableModel, já que só serve para programadores preguiçosos fazerem programas confusos.

Implementação do generics sem reification e com erasure também foi um erro, na minha opinão.

Sem falar na API de datas, já citada.

A classe Enumeration era usada antes das Collections serem implementadas, e continua lá apenas por compatibilidade com programas antigos do Java. Qualquer novo software deve usar o Iterator.

thingol:

Generics sem reification* foi uma péssima idéia. O próprio gerente da implantação do Generics no Java 5.0, o Neal Gafter, gostaria de ter incluído a reification, mas isso iria quebrar a JVM (que não iria ser substancialmente modificada no Java 5.0).

• Por exemplo: poder declarar List e tal declaração usar internamente um array de int mesmo.

Reificação é uma boa, mas do ponto de vista do desenvolvedor não muda nada. O fato disso “incomodar” tanta gente tem mais a ver com fatores psicológicos do que algum ganho real de produtividade.

Ter as exceções bem documentadas é ruim? Como? Por quê?

Java ainda permite que você use RuntimeExceptions, portanto o que você advoga é não ter opção ao invés de poder usar checked e non-checked exceptions? Que o desenvolvedor ganha com menos opções?

Trabalhar com pointer? Mas que isso acrescenta no desenvolvimento de software? Nada, absolutamente nada.

eduveks:

Ou seja… doGet e doPost além de não fazer sentido, sujam o código, um tapinha na orelha do cara q inventou isto!

Acho q só em Java q inventaram este conceito de GET e POST separados, como se fosse coisas independentes…

Meu Deus do céu, quanta bobagem! Você tem problemas com opções para desenvolvedor? E se não for desejável receber request em GET e apenas em POST? Precisaria fazer if/else?

Cara, quer criticar critique, mas pelo menos diga algo que faça sentido.

victorwss:

Que tal o maior anti-pattern em java de todos os tempos? A convenção de nomenclatura JavaBeans?

Se o método tiver um nome que inicia com get<letra maiúsula> ele se torna um método mágico! set<letra maiúsula> também o deixa mágico!

O negócio é entupir suas classes de getters e setters públicos!

Convenções de código existem em qualquer linguagem.

Na verdade, também não gosto das checked exceptions. Muitas vezes elas te obrigam a colocar try…catchs em pontos onde o sistema não pode fazer nada. Torna o código centenas de vezes mais confuso, só para você poder lançar novamente uma exception runtime, ou gerar um log. Veja o caso da SQLException. Não é à toa que APIs como o Spring, a eliminaram completamente.

A primeira vez que li o artigo contra as checked exception no Artima, não concordei. Mas aí passei a prestar atenção, e perceber que elas realmente trazem mais mal do que bem.

Checked exceptions também passam a fazer parte da assinatura do método. E isso prejudica a escalabilidade de uma API. Note que uma vez publicada, você não tem mais a opção de fazer com um método lance uma nova CheckedException, sem quebra-lo. E omitir uma checked exception existente (pq o método não a lança mais), fará com que seus usuários recebam centenas de warnings.

O desenvolvedor tem opção ao criar exceptions, mas não ao usa-las.

Concordo.

A questão está sempre em quanto tempo manter retro-compatibilidade. Fazer um programa Java 5 suportar uma compilação Java 1, só pela compatibilidade é uma boa? E porque não separar essas classes num pacote “oldstuff.jar” e deixar isso de fora das versões novas do JDK?

Ganha-se produtividade quando numa aplicação de performance mais crítica, pode-se usar lists no lugar de vetores primitivos. Boxing e unboxing tem seu preço.

Na verdade, também não gosto das checked exceptions. Muitas vezes elas te obrigam a colocar try…catchs em pontos onde o sistema não pode fazer nada. Torna o código centenas de vezes mais confuso, só para você poder lançar novamente uma exception runtime, ou gerar um log. Veja o caso da SQLException. Não é à toa que APIs como o Spring, a eliminaram completamente.

Não precisa usar try/catch, basta adicionar um throws no método para quem quer que use aquilo se vire para cuidar do erro. E ainda isso é automático em IDEs como o Eclipse e Netbeans, ou seja, nem o trabalho de digitar isso você tem.

ViniGodoy:

A primeira vez que li o artigo contra as checked exception no Artima, não concordei. Mas aí passei a prestar atenção, e perceber que elas realmente trazem mais mal do que bem.

Existem runtime exceptions para isso. Se houvesse apenas checked exceptions eu concordaria, mas é dada a opção ao desenvolvedor de usá-las ou não.

Pelo visto você não entende absolutamente nada de desenvolvimento em camadas. Simplesmente repassar um “throws sem trabalho algum” fere o encapsulamento das camadas. Pense bem, faria sentido você ter um método de camada de negócio que dispare um SQLException? E se esse método tiver um mecanismo de persistência injetado, para salvar, por exemplo, em arquivo e bd, ele disparará IOException e SQLException? Obviamente não.

Pior do que isso, o sistema não tem como se recuperar de nenhuma dessas duas exceptions, e o programador está tendo que se incomodar com elas.

Claro, vc ainda poderia manter essa filosofia, e fazer um throws Exceptions em absolutamente todos os métodos, para cedo ou tarde, cair num método de log. Mas aí, para que checked exception? Isso é equivalente a desligar completamente o mecanismo.

O C# não tem checked exceptions. E para ser bem sincero, não só não estou sentindo nenhuma falta, como estou agradecendo por isso.

Leu a entrevista?

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

Uma coisa bem esquisita: os métodos defaultWriteObject() e defaultReadObject() não fazerem parte de nenhuma interface.
Simplesmente implementar na classe torcendo para a assinatura estar certa não parece Java… tem mais a ver com aquelas funções de callback da API do windows.

Eu acho que estes métodos deveriam estar em uma interface CustomSerializable ou algo do tipo.

Não fere nada. De qualquer forma quando um erro ocorre uma exceção será lançada, seja ela checked ou não. A única diferença é que com checked exceptions você sabe o que esperar. E se realmente há a necessidade da camada de negócio dar um tratamento especial para o erro, então aí está mais uma razão para o try/catch e o tratamento correto do que ocorre.

Em ambos os casos, quando não há o que fazer e quando há o que fazer, os checked exceptions não atrapalham em nada.

ViniGodoy:

Pior do que isso, o sistema não tem como se recuperar de nenhuma dessas duas exceptions, e o programador está tendo que se incomodar com elas.

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.

ViniGodoy:

Claro, vc ainda poderia manter essa filosofia, e fazer um throws Exceptions em absolutamente todos os métodos, para cedo ou tarde, cair num método de log. Mas aí, para que checked exception? Isso é equivalente a desligar completamente o mecanismo.

Mas se tem gente que deseja retirar essa feature da linguagem… é melhor ignorá-la, e usá-la quando for necessário do que simplesmente retirá-la por uma questão puramente psicológica.

ViniGodoy:

O C# não tem checked exceptions. E para ser bem sincero, não só não estou sentindo nenhuma falta, como estou agradecendo por isso.

Quais são as vantagens? Não tratar erros? Interessante, deixe o seu aplicativo falhar horrivelmente.

ViniGodoy:

Leu a entrevista?

Sim, e assim como o pessoal daqui, é fraquíssima.

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

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.

Thiagosc:

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

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.

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.

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.

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.

Thiagosc:

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

Ó, 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?

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.

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?

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.

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

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.

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.

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 .

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

:shock: :shock: :shock:

Quanta besteira vc fala…

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.

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.

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.

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.

Isso aqui é um argumento?

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?

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.

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.

ViniGodoy:

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.

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.

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

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)

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

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.

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.

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

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

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

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.

API de datas ++ a pior rs.

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:

public class A {

    public A() {
        
 	   doSomething();
    }
    
    protected void doSomething() {
        
        System.out.println("Saying something from A");
    }

    public static class B extends A {
        
        private String hello = new String("Hello my friend!");
     
        public B() {
            super();
        }
        
        @Override
        protected void doSomething() {
            
            System.out.println("Saying from B: " + hello);
        }
    }

    public static void main(String[] args) {

        new B();
    }
}

Daí quando executo:

C:\java>java A
Saying from B: null

Trivial né?

Eu estava dando manutenção num sistema e me deparei com isto:

for (String msg : listaMsgs) {
		throw new ValidationException(msg);
	}

Tive q postar aqui hehehe