Piores erros do java

Assuntos Gerais
#1

Bem pessoal, crio este tópico para debater acerca dos piores erros cometidos no java, o que poderia ter sido feito para evitá-los e como o mundo seria hoje se esses problemas nunca tivessem ocorrido.

O primeiro que considero é java.util.Date, java.sql.Date, java.sql.Timestamp, java.util.Calendar e java.util.GregorianCalendar. Acredito que todos que já trabalharam com datas no java já tiveram vontade de queimar em praça pública o imbecil que bolou essas classes por heresia.

Ter java.util.Enumeration e java.util.Iterator ao mesmo tempo também é uma idéia muito muito ruim.

Comentem!

#2

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.
#3

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!!! :slight_smile: :smiley: :lol:

#4

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

#5

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

#6

API de datas é uma desgraça!

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

#7

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…

#8

O tal do EJB 2.0/2.1 sem comentarios.

#9

[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]

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

#10

[quote=eduveks][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]

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

Que tal SingleThreadModel?

#11

[quote=eduveks][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]

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

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

#12

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

#13

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

#14

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

#15

[quote=maior_abandonado][quote=eduveks][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]

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

kra eu so meio iniciante, desculpe minha ignorancia mais…pq???[/quote]

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:

[code]
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);
}[/code]

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…

#16

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!

#17

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

#18

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

#19

Em breve isso muda. Com ajuda do Michel Nascimento(Mister M).
[/quote]

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.

#20

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