Ol� a todos,
segue a segunda parte da mensagem...
>__| J2EE x .NET: A Batalha de 2002 Est� Apenas Come�ando (Final) |__
>O colega Joel de Sousa Ribeiro de Melo - [EMAIL PROTECTED], nos enviou
>o excelente texto abaixo, da Developers' Magazine, N�mero 66 -
>FEVEREIRO/2002, que por motivo de tamanho foi dividido em duas partes. Este
>texto foi escrito por Osvaldo Doederlein, [EMAIL PROTECTED], e aqui
>apresentamos a parte final.
>
>N�o demorou muito e a Oracle respondeu pela comunidade J2EE, "provando" que
>o JPS (acrescido de poucas otimiza��es e executado no seu application
>server) surra a .NET, com desempenho at� 22 vezes superior que a vers�o da
>Microsoft. Tendo experi�ncia com benchmarking, se me perguntarem em qual
>vers�o eu acredito, diria: ambas e nenhuma delas. O maior problema � que o
>JPE � um tutorial, n�o um benchmark, prestando-se a manipula��es e n�o
>representando bem o comportamento de aplica��es J2EE. Como a J2EE possui um
>benchmark oficial, s�rio e cient�fico, o ECPerf, seria mais produtivo se a
>Microsoft fizesse um porte desse programa e n�o de um brinquedo.
>
>Outra controv�rsia interessante � a quest�o dos padr�es. Ambas as partes
>definem sua pr�pria tecnologia como "aberta" e a concorrente como o Java
>"propriet�ria". O ponto de vista da Microsoft se fundamenta nos padr�es ECMA
>da linguagem C# e outros itens de import�ncia marginal (basicamente,
>especifica��es para a cria��o de linguagens compat�veis com .NET). A
>Microsoft mant�m controle de elementos cr�ticos da .NET, a plataforma �
>ainda mais amarrada a seus pr�prios produtos e estrat�gias do que tudo que
>substitui. At� mesmo os itens submetidos ao ECMA ter�o novas vers�es
>desenvolvidas isoladamente pela Microsoft (a Microsoft j� planeja uma
>atualiza��o do C#, com suporte a tipos gen�ricos. Talvez o ECMA carimbe a
>nova vers�o da Microsoft, ou talvez a Microsoft nem se importe em padronizar
>tais novas vers�es).
>
>A Sun n�o tem a chancela de um �rg�o independente, mas h� compensa��es. A
>totalidade da plataforma Java, desde a Virtual Machine at� a �ltima das
>APIs, � dispon�vel em c�digo-fonte - a licen�a SCSL n�o � aceita como open
>source "puro", como a GPL ou BSD, pois n�o permite livre redistribui��o de
>modifica��es (para impedir a prolifera��o de dialetos incompat�veis). Por
>outro lado, h� liberdade para uso privado, sendo poss�vel usar o c�digo
>original ou aperfei�oado at� em software comercial, sem pagamento nem
>contribui��o das modifica��es � Sun. Numa coisa a Microsoft e Sun (e v�rias
>empresas que tentaram fazer dinheiro com software livre) concordam: a GPL
>n�o combina com neg�cios. A Sun montou seu pr�prio �rg�o de padr�es, o JCP
>(Java Community Process). O JCP � bastante aberto, mas d� poderes especiais
>� Sun (como o direito de escolher o chair de cada JSR) que o tornam menos
>imparcial que outros �rg�os. Todavia, o JCP � legitimado pela participa��o
>de mais de 400 membros, incluindo praticamente todos grandes players da
>ind�stria. E funciona de forma mais �gil e eficiente que a maioria dos
>�rg�os de padr�es tradicionais, tendo evitado os problemas de tecnologias
>geradas por comit�s.
>
>Na compara��o entre os padr�es de papel ECMA vs. JCP, pode-se discutir
>longamente qual � o mais bonito. Mas na prova dos nove, o Java h� tempos
>exibe uma fartura de provas do seu lado "open" com milhares de produtos
>independentes em dezenas de plataformas. � a Microsoft que tem o �nus da
>prova - a op��o da Microsoft por um runtime port�vel � necess�ria porque o
>futuro do Windows depende da migra��o para a nova arquitetura de 64 bits da
>Intel, incompat�vel com o legado de 32 bits. A Microsoft teve uma dura
>experi�ncia tentando convencer os desenvolvedores a portar aplica��es NT
>para MIPS, PPC e Alpha. Os mercados de devices como PDAs e celulares tamb�m
>abundam em arquiteturas diversas.
>
>A Arte da Guerra. Posicionar-se bem no terreno � meio caminho andado para a
>vit�ria. Existem vantagens nas posi��es de ambos ex�rcitos. A plataforma
>Java encontra-se na confort�vel posi��o de tecnologia conhecida, comprovada,
>e confi�vel. Cases de sucesso J2EE j� deixaram de ser novidade. A linguagem
>Java j� ultrapassa C++ em popularidade. A Sun Microsystems pode n�o ter
>porte para enfrentar a Microsoft, mas o Java � suportado por um time que
>inclui IBM, Oracle, Borland, BEA, Iona, Fujitsu e, praticamente todo mundo
>que conta, exceto a Microsoft. Sem falar na enorme popularidade do Java nas
>academias de todo o mundo. A import�ncia disso n�o pode ser subestimada;
>al�m da oferta de profissionais, inclui milhares de mestrandos e doutorandos
>fazendo pesquisas que beneficiar�o o Java direta ou indiretamente. O mesmo
>pode ser dito do open source: n�o h� competi��o .NET para produtos como o
>Tomcat, JBoss, NetBeans, Eclipse e muitos outros free.
>
>A Microsoft tem uma capacidade de engenharia gigantesca e est� fazendo uma
>grande aposta no sucesso da .NET. Mas a nova plataforma, por melhor que
>pare�a ao executar demos, carrega a marca de release "1.0" de um produto de
>enorme complexidade. Os mais conservadores ficar�o longe disso por um ano ou
>dois, at� que a .NET prove ser robusta, escal�vel, segura, etc. Mas se ainda
>existe muito terreno para conquistar, a Microsoft conta com muitos
>desenvolvedores que usam e continuar�o usando sua plataforma, e a enorme
>massa de c�digo existente que ser� mais f�cil de migrar para o mundo .NET do
>que para J2EE. A estrat�gia da Microsoft � seu argumento mais forte: .NET �
>o seu futuro. Isso j� foi dito antes de iniciativas como o DNA, mas
>diferente desses epis�dios, a .NET n�o � apenas uma jogada de marketing ou
>um nome novo para as mesmas coisas. � a maior reforma do Windows desde a
>transi��o de 16 para 32 bits. Nesse combate, � poss�vel que muitos soldados
>mudem de lado. Quem desenvolve em J2EE porque gosta da tecnologia, mas n�o
>se importa muito com independ�ncia de plataforma e de vendedor, encontrar� a
>NET um ambiente familiar, uma curva de aprendizado macia, e os benef�cios
>do acesso total �s particularidades do Windows. Quem vive no mundo Windows
>mas n�o � f� da Microsoft, ver� que o esfor�o de migra��o para .NET �
>praticamente o mesmo de escolher J2EE: aprender novas linguagens,
>bibliotecas de classes, IDE's e talvez at� m�todos de desenvolvimento. Esse
>desenvolvedor pode ter resistido ao Java por in�rcia, ou por desconfiar de
>conceitos como m�quinas virtuais, mas agora ser� praticamente obrigado a
>escolher uma das novas plataformas e poder� apreciar a natureza muito mais
>aberta e a maior maturidade, do Java.
>
>Ambos competidores dominam territ�rios importantes. J2EE tem grande presen�a
>no mercado corporativo, no chamado "server side" que � o maior sucesso do
>Java hoje. Igualmente importante � o tremendo avan�o que o Java est� fazendo
>no mundo dos dispositivos PDA, wireless, sistemas embutidos, TV, ou seja no
>mundo "micro" que � o pr�ximo grande front de lucros e de oportunidades. O
>J2ME � praticamente o padr�o, de fato e de juris, de plataformas como
>telefones celulares e aparelhos de TV de nova gera��o; j� a Microsoft,
>malgrado as boas vendas do Windows CE, tem amargado uma cole��o de derrotas
>nesses mercados. Em compensa��o, a Microsoft ostenta a invej�vel posi��o de
>monop�lio do desktop, com centenas de milh�es de usu�rios. Esse mercado pode
>estar relativamente estagnado (todo mundo j� est� dentro), mas ainda � muito
>lucrativo e pode ser usado para alavancar iniciativas em novas plataformas.
>
>
>Conclus�o. Ao inv�s de listar e comparar tecnicalidades como as min�sculas
>diferen�as entre as linguagens Java e C#, ou mesmo diferen�as de
>funcionalidade de APIs ou ferramentas visuais que mudam rapidamente, devemos
>dar aten��o aos elementos essenciais da tecnologia e da estrat�gia de longo
>prazo de cada competidor, nessa batalha pelo padr�o de plataforma de
>desenvolvimento para a pr�xima gera��o tecnol�gica. As empresas e
>profissionais decidindo por uma dessas plataformas estar�o fazendo grandes
>investimentos em capacita��o, aquisi��o de produtos, e construindo sistemas
>que ter�o que ser mantidos por muito tempo. O cen�rio atual � favor�vel �
>J2EE, mas reconhecemos que muitas vezes a vantagem � somente de j� haver
>comprovado alguma qualidade, sendo perfeitamente poss�vel que a .NET venha a
>possuir a mesma vantagem (por exemplo, ser uma tecnologia aberta de fato)
>mas, como o seguro morreu de velho, e o background da Microsoft e de seus
>produtos dep�em contra a propaganda da .NET, essa plataforma ter� um longo
>desafio pela frente.
>
>Fechando com um lugar comum, h� pouca d�vida que ambas plataformas ir�o
>coexistir e ter boas fatias do mercado. A maior quest�o � quem ficar� com a
>maior fatia, no todo ou em cada setor e nicho. O ponto positivo desse
>cen�rio � que os padr�es XML e de Web services (especialmente SOAP) oferecem
>um grau in�dito de interoperabilidade entre os competidores. Na pior
>hip�tese (ou seja: caso a sua plataforma favorita n�o seja t�o dominante que
>voc� possa ignorar o "resto"), ser� muito mais f�cil que antigamente
>construir sistemas que precisam ser cada vez mais integrados, num mundo que
>se torna cada vez mais heterog�neo.
>
>Autor: Osvaldo Doederlein - [EMAIL PROTECTED], � coordenador de
>projetos da Visionnaire Inform�tica.
