Em mais uma post da série que tem feito programadores Java perderem o sono, Java’s Signal of Failure (JSF).

Hoje o problema é bem leve, mas envolve um mal que persegue muitos programadores. Documentação.

A classe de hoje é java.awt.Container. Logo no início dela, existe a declaração de um atributo do tipo int. Aqui está o trecho de código:

/**
 * The number of components in this container.
 * This value can be null.
 * @see #getComponent
 * @see #getComponents
 * @see #getComponentCount
 */
int ncomponents;

Normal, não fosse um pequeno detalhe. “This value can be null”. Como assim? É um int. Obviamente não pode ser null. Tipos primitivos não aceitam null. O que deve ter acontecido é que ncomponents (nome bonito para uma variável, não?) deveria ser um java.lang.Integer, mas trocaram para int posteriormente. Pena que não viram o comentário perdido por ali.

Mais uma razão para valorizar a expressividade ao invéz dos comentários.

Posts Relacionados:

Gerando memória swap on-the-fly

JSF - SOAPConnection

JSF - Java’s Signal of Failure

Linguagens de Programação - Java

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Continuando com a série Java’s Signal of Failure (JSF), uma saída esperta e preguiçosa.

Dêem uma olhada no seguinte método da JDK 6, da classe javax.xml.soap.SOAPConnection

public abstract SOAPMessage call(SOAPMessage request, Object to);

Prestem bastante atenção no último parâmetro que o método recebe. Isso mesmo. Um brilhante e magnífico java.lang.Object. Depois de ficar chocado com a assinatura, decidi dar uma olhada na documentação pra ver se entendia essa bizarrice.

Seja quem for que criou esse método, quis evitar que quem estivesse criando sua própria SOAPMessage precisasse sobrescrever três métodos. Por isso, ele recebe um object, mas deve ser um java.lang.String, java.net.URL ou um javax.xml.messaging.URLEndpoint.

Agora, esse foi um dos piores lugares em que eu já vi um Object. Por que raios não usaram sobrecarga de método? Custava deixar a API nojenta de SOAP um pouquinho mais legível?

Erro feio esse! O que será que acontece se eu passar um Long pro método? Exception? Devolve null? O comportamento que deveria ser padrão não está documentado. Triste, não?

Posts Relacionados:

JSF - Container

JSF - Java’s Signal of Failure

Linguagens de Programação - Java

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Java é uma das linguagens mainstream do momento. Alguns gostam, outros odeiam… Afinal, o que torna essa linguagem tão popular e impopular ao mesmo tempo? Quais são os pontos fortes e fracos dessa linguagem criada pela Sun na década de 90 e que é atualizada até hoje? Vamos analisar a linguagem de uma maneira global antes de destrui-la de vez na série JSF :)

Java é uma linguagem de tipos estáticos e explícitos, ou seja, você tem que declarar o tipo de sua variável. Junte a isso os modificadores de acesso, sincronismo e gravação e você terá uma ideia da burocracia da linguagem. Isso é visto como uma desvantagem por muitos, mas também tem suas vantagens. Se, por um lado, perde-se flexibilidade, por outro ganha-se em segurança.

Os criadores de Java procuram sempre manter compatibilidade entre as versões da linguagem. Isso significa que código das primeiras versões do Java ainda são compiláveis pelos compiladores para as novas versões sem ser necessário alterar o código. Essa decisão é boa para as empresas que trabalham com muito código legado mas é ruim para a linguagem. Por causa disso, decisões erradas sobre diversos aspectos da linguagem são visíveis até hoje. Por causa disso, também, a linguagem tem poucas (55) palavras reservadas, mas cada uma podendo ter mais de um significado dependendo do lugar em que aparece, o que gera confusão e implica em sintaxe pouco intuitiva em muitos casos (vide classes anônimas, blocos construtores, a sintaxe do enhanced for, etc).

Por esses aspectos já dá para notar porque a linguagem ficou tão popular: porque as empresas gostaram. A linguagem é padronizada, burocrática e não exige manutenção conforme é atualizada. Perfeito para elas! Não tanto para os programadores…

Como um dos objetivos iniciais da linguagem era a portabilidade dos programas, foi decidido que os programas seriam executados em uma máquina virtual. Uma crítica que muitos opositores de Java fazem é que isso torna os programas mais lentos e “pesados”. De fato, se considerarmos que a máquina virtual é uma camada a mais na execução de um programa, é lógico concluir que isso vai tornar a execução mais lenta. Isso era uma realidade incômoda até pouco tempo atrás mas, recentemente, as máquinas virtuais para Java evoluíram a tal ponto que a velocidade de execução de um programa em Java é comparável com a de um programa em C. Devemos considerar, é claro, que isso acontece depois de algum tempo de execução, quando a máquina virtual já carregou e otimizou o código. Mas o fato é que as máquinas virtuais para Java estão tão boas que outras linguagens interpretadas (ou seja, que rodam em máquinas virtuais) estão utilizando a máquina virtual Java para executarem o código. Dois exemplos disso são o projeto JRuby, para executar código Ruby, e a linguagem Groovy, que foi escrita já com o intuito de ser facilmente executada na máquina virtual de Java.

Para concluir esse post (mas não necessariamente o assunto), podemos dizer que a linguagem já está, digamos, velha. Isso também tem suas vantagens e desvantagens. As vantagens são a tecnologia bem desenvolvida sobre ela (o que inclui a máquina virtual) e a grande quantidade de ferramentas para se trabalhar com ela (bibliotecas e ambientes de desenvolvimento). A principal desvantagem, acentuada pela decisão de compatibilidade com versões anteriores, é a dificuldade de evoluir a linguagem, dadas as decisões erradas de arquitetura e a quase-impossibilidade de alterar sua sintaxe.

Posts Relacionados:

Linguagens de Programação - Basic

Linguagens de programação - C++

Linguagens de Programação - C

Linguagens de programação

Testes unitários em C++

Lambda the Ultimate

VidaGeek.net agora também é Fórum!

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.

Não. Isso não é um post para falar mal de JSF (embora eu tenha motivos para isso). É apenas o começo de mais uma série com um nome quase comico e estranho (como SNL e INC).

Mas sobre o que é essa série? Bom, toda linguagem de programação, conforme envelhece, começa a apodrecer. Se você ainda tiver uma filosofia de manter 100% de compatibilidade com as versões anteriores, muito lixo começa a se acumular. O Objetvo dessa série e mostrar parte desse lixo que tenho encontrado durante esse tempo que trabalho com java.

Chega de enrolar vocês. Vamos à um dos casos que mais me dá calafrios.

public class Stack<E> extends Vector<E>

Essa é umas das linhas mais assustadoras que encontrei passeando pelo código da JDK. O que ela diz? Que uma pilha É um vetor. Por que isso é ruim? Vamos lá!

1. A pilha é uma estrutura que depende da ordem em que os elementos se encontram dentro dela. Mas como é um Vector, você pode alterar qualquer posição dela sem problemas. Isso destrói qualquer algoritmo que dependa de uma pilha.
2. Alguém notou que Stack é uma classe e não uma interface? Esqueçam qualquer possibilidade de uma outra implementação para pilhas. Se você usar uma Stack, seu código estará preso à essa implementação. Modificações de comportamento só podem ser feitas via herança, o que é péssimo.
3. Stack deveria ser um objeto com pouquissimas operações. No entanto, se você olhar a API pública de Stack verá muitos métodos. Muito mais do que deveria existir. Mais complexidade para seu dia de trabalho.
4. Isso foi feito por preguiça! Qualquer aluno de Ciência da Computação faria uma classe Pilha que TEM um Vector.

Paro por aqui pois ainda tem muita sujeira por vir.

Posts Relacionados:

JSF - Container

JSF - SOAPConnection

Linguagens de Programação - Java

Nokia ConnectUsp conecta mas não navega

Ubuntu planeja versão móvel

Webcomics para Geeks: xkcd

Dia C - Modificadores e extensões GNUC

Acompanhe-nos por RSS, por Email ou via Twitter.
Veja como ter um desconto no Dreamhost: um excelente servidor web.