Popular Tags:

Java é Lento?

13/08/2013 at 00:24

Eis a dúvida cruel que persegue todo programador Delphi: “Java é lento porque é interpretado”.

As primeiras JVMs eram simplesmente interpretadores de bytecodes, liam arquivos .class e traduziam cada bytecode na sequência de execução para as instruções de máquina equivalentes. A partir do Java 1.1, a Sun incluiu seu primeiro JIT Compiler, adquirido da Symantec, e, no Java 1.2, incluiu o HotSpot. A evolução dessas duas tecnologias ao longo das versões do Java faz com que ele seja equiparável a aplicações nativas em C e C++.

Os grandes ganhos de performance do Java devem-se à otimização adaptativa, isto é, a capacidade de fazer otimizações de acordo com o uso do programa e as condições do ambiente. Tanto Java quanto C possuem uma etapa de compilação estática, que gera um arquivo binário a ser executado, e, durante essa compilação, várias otimizações são realizadas. A diferença é que o binário nativo C gerado é executado diretamente na máquina, e o binário Java é executado através da JVM, onde outras otimizações acontecem. No caso do C, toda otimização possível é feita estaticamente pelo compilador, enquanto que o Java consegue executar a segunda etapa de otimizações dentro da VM no momento da compilação dos bytecodes para código nativo, na chamada compilação dinâmica. É isto o que faz o Java executar tão rapidamente.

Porquê Java

04/08/2013 at 12:40

Delphi é excelente como plataforma RAD – Rapid Application Development, mas quando você entrega seu primeiro grande software veem as mudanças solicitadas pelos usuários, natural, mais natural ainda é causar impactos negativos nas versões posteriores porque foi RAD.

Então você tem certeza que a famigerada Orientação a Objetos apresentada na faculdade não era aquela utopia de que provavelmente deveria ser utilizada em sistemas não visuais e gigantescos, não. O que você aprendeu foi utilizado para manipular um componente-não-visual ou outro, o básico de instanciação e ciclo de vida de objetos, etc.

Após aquela triste constatação você arregaça as mangas, enterra a cabeça nos livros e sites e tenta aplicar OO no Delphi, que por sinal também é excelente em OO, sem dúvida, mas tem tanto RAD no Delphi que chega a atrapalhar nesse caso, e ai vem minha visão dos defeitos do OO no Delphi.

O primeiro defeito é que ele obriga criar a assinatura do método e a implementação, ou seja, mesmo que o editor tenha a tecla de atalho Ctrl+Shift+C para criar a implementação, você ainda tem que fazer alterações menores de forma manual, nem pense em utilizar o recurso de refatoração, pois ele não se aplica aos parâmetros de entrada nem de saída, isso quando funciona. Observe o código abaixo.

Em Java ou C# é num lugar só, a implementação já é a assinatura. Muito mais prático e menos cansativo.

O segundo defeito é o Delphi publicar todos os objetos do form ou datamodule sem seu consentimento. Isso fere a regra básica de encapsulamento atrapalhando trabalho em equipe, pois um novato ou um desavisado ou você mesmo após uma noite mau dormida pode utilizar um atributo publicado a partir de outro form e isso causará problemas no futuro eu garanto. Essa revelia ao encapsulamento é por causa de quem? Do RAD! Do ponto de vista de desenvolvimento RAD isso é uma maravilha, agiliza as coisas, mas é como cartão de crédito, passa fácil na maquininha, duro é pagar a conta. Observe o código abaixo, por definição o Delphi “enxerga” com escopo published, os outros escopos private e public você utiliza manualmente, e se você mover a declaração de algum objeto do published para o public não vai funcionar porque os objetos do escopo published são instanciados, inicializados e destruídos automaticamente pela VCL, bem como todos os objetos do escopo published são listados no object inspector da IDE.

O terceiro defeito do Delphi foi o enorme atraso no binding de objetos na camada visual, chegou tarde e quando chegou veio com o design mais difícil do mercado (o binding por definição), Java tem a Expression Language no JSF, que funciona da seguinte forma: digamos que você tem um campo texto na tela para o usuário digitar o e-mail, então basta você declarar uma variável no managedbean com o tipo da entidade e usar direto na página html. Observe o exemplo abaixo, não existe fieldslist nem fieldByName.

Você pode achar estranho responder a pergunta do porque Java elencando os pontos negativos do Delphi, você pode perguntar: Mudar para Java por causa dos defeitos do Delphi?! E eu diria: com certeza! O Java não tem esses problemas e está na web. Mas atenção, não conheço plataforma que supera o Delphi para Desktop, tanto visualmente quanto produtivamente em termos de suporte em forums, blog, e uma tonelada de biblitecas prontas para o que der e vier. Mas em termos de evolução o Delphi ficou para trás há muito tempo, mesmo com o aporte do generics, annotations e métodos anônimos.

E quem disse que estou mudando de Delphi para Java? Pouco provável, estou apenas adotando-o para web, que é onde o Delphi não chegou e não vai chegar tão fácil, e eles mesmos sabem disso, tanto é que a última investida deles através do XE4 foi para compilação nativa para mobile (iOS) e o roadmap indica outro caminho.

Existe proposta robusta do Delphi para web? Sim, mas é ingênua, e não estou falando sobre Intraweb, esse ai morreu. A parte ingênua diz respeito a esperar que programadores Delphi desenvolvam servidores Datasnap que respondam com JSON para a camada visual ser escrita puramente em html, javascript e css. Isso aumentou a curva de aprendizado absurdamente. Com Java & JSF o programador Delphi precisa apenas entender como os managedbenas e EJB funcionam e o básico de html, pois javascript e css ficam por conta de frameworks como o primefaces. Portanto, por incrível que pareça é mais fácil o programador Delphi sair dele para chegar na web.

Agora preciso explicar porque Java e não C#, esse é mais simples, quando procurei por tecnologias para web anos atrás, foi com o C# que comecei, a curva de aprendizado em termos de IDE e plataforma para quem vem do Delphi parecia ser menor, o problema que encontrei foi conseguir bons resultados sem pagar por componentes caríssimos.

Java, portanto, veio por exclusão, ele foi o último a ser escolhido para o time, mas não me arrependo, pelo menos tenho certeza de que serve, principalmente para produzir trabalhos particulares, pois não é ético utilizar licenças da empresa onde você trabalha, e com Java não tenho esse problema.

O segundo e grande benefício do Java é a vanguarda que ele se encontra e as empresas que estão por trás da JCP – Java Community Process. O terceiro benefício é a literatura sobre software em geral, quando você estuda OO, Design Patterns e Arquitetura de Software a maioria esmagadora dos livros menciona Java.

O quarto ponto positivo está na liberdade de IDE, em Java você pode escolher entre Eclipse, Netbeans, IntelliJ IDEA, JDeveloper, Notepad++, etc.

Por fim mas não menos importante, está a capacidade de ser multiplataforma, gosto da liberdade de poder atender o cliente se ele prefere que seu servidor seja Unix based.