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…[/quote]
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.[/quote]
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[/quote]
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…[/quote]
Pois é, a muito tempo que eu desejo ver um gigantesco @Deprecated carimbado com letras vermelhas nestas classes infames.
[/quote]
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 
[quote=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…[/quote]
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
[quote=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
[/quote]
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”.
[quote]
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.[/quote]
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.
[quote=sergiotaborda][quote=victorwss]
E falando em mau uso de herança. Voltamos a java.sql.Date e java.sql.Timestamp.
[/quote]
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
[/quote]
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.
[quote=sergiotaborda]
[quote=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.[/quote]
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. [/quote]
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…
[quote=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…[/quote]
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)
[quote=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…[/quote]
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…