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

Lambda the Ultimate

Testes unitários em C++

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.

Voltando hoje com a nossa série “Linguagens de Programação”, temos um post de um de nossos leitores: André Luis Zary Mariano da Silva. André tem 17 anos, mora em Porto Alegre e é estudante do primeiro ano do ensino médio, técnico em informática e programador freelancer. Também escreve o blog “C, C++, Java e baboseiras”.

Visual Basic: uma versão de Basic adaptada para criar aplicações gráficas com rapidez

Basic é utilizada na área de programação como uma linguagem de ensino da lógica. Claro que hoje é sem sentido dizer que ainda se usa Basic puro comercialmente. Temos o QBasic (Quick Basic a mesma do Free Basic), ou o Visual Basic, que são uma espécie de modernização da linguagem - do mesmo jeito que aconteceu com a BCPL (a BCPL foi modernizada para B que, por sua vez, foi para C).

O motivo dessa linguagem ser usada no ensino da lógica é porque ela foi desenvolvida para ser uma linguagem extremamente de alto nível, ou seja, bem próxima da linguagem humana. No caso do VB e do QB, o inglês e, no caso do FreeBasic, o português.

O principal benefício do Basic é que se pode criar aplicações de baixo e médio porte com relativa simplicidade e rapidez, enquanto que, em outras linguagens, como o C/C++ e Java, o processo é mais longo.

Um dos males do Basic é que a biblioteca de funções não é externa, e sim interna, ou seja, junto a linguagem. Mas ainda é uma linguagem muito divertida por:

• Ser fácil para ser utilizada por iniciantes na programação (tanto por hobby ou profissão);
• Ser uma linguagem de programação para qualquer coisa;
• Permitir que fossem adicionassem características avançadas, sem tornar a linguagem mais complicada para os usuários;
• Fornecer mensagens de erro claras e amigáveis;
• Responder rapidamente para programas pequenos;
• Não exigir o conhecimento do hardware do computador (o que assusta muito os iniciantes);
• Proteger o usuário de erros causados pela má programação no sistema operacional.

Ainda hoje, mesmo já conhecendo outras linguagens, muitos escrevem funções nela, já que a sua sintaxe é extremamente parecida com a da pseudo-linguagem, o que torna fácil depois a passagem para a linguagem utilizada no projeto.

Então, analisando-se a linguagem pode-se dizer que, mesmo sendo uma linguagem “amadora” (como ainda hoje em dia é chamada), é muito útil tanto pelos motivos ditos acima como, por exemplo, influenciar linguagens, como no caso do Visual Basic.Net e do VBScript, dando chance, assim, para que amadores possam continuar com uma linguagem relativamente simples e usando recursos modernos.

Imagem retirada do site http://esafonsosanches.nonio.uminho.pt/course/view.php?id=76

Posts Relacionados:

Visual Basic no Linux

CodeIDE

Construção de interfaces com o Glade

Lambda the Ultimate

Linguagens de Programação - C

Linguagens de programação - C++

Aprenda Comandos Básicos de Linux

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