Prosseguindo com a sequência de colunas sobre as comparações entre linguagens de programação, neste artigo vamos comparar o Java ao .NET.
Antes que sigam as críticas, cabe esclarecer que o .NET não é uma linguagem, e sim uma plataforma da Microsoft que permite a utilização de diversas linguagens, como C#, Visual Basic, J# e ASP. Vamos focar então a comparação na construção de aplicações web, utilizando J2EE e o framework ASP NET da Microsoft, que é onde as duas linguagens mais competem.
Comecemos pela questão das licenças de uso, que influenciam diretamente no TCO (para referência aos fatores sendo comparados, consultar na minha coluna Fatores para Escolha da Linguagem de Programação). Apesar da Sun deter a marca Java, a mesma tornou a linguagem open source, permitindo aos usuários efetuar alterações convenientes. Para a plataforma .NET, existem algumas iniciativas free, como os projetos Mono e DotGNU. Porém, para se aproveitar todo o potencial da plataforma, é praticamente necessário se adquirir o servidor Microsoft juntamente com o ambiente de desenvolvimento Visual Studio. Sem estas ferramentas, além de não se aproveitar tudo o que se tem, a velocidade de desenvolvimento fica fortemente prejudicada. Além disto, nada na Microsoft é open source.
No item escalabilidade, as implementações das duas plataformas provêem mecanismos de balanceamento de carga, permitindo habilitar um cluster de máquinas para servir às cargas dos usuários que forem aumentando ao longo do tempo. A grande diferença entre o J2EE e o .NET é que desde que o .NET suporta apenas Win32, um número maior de máquinas se faz necessário, comparando ao J2EE, devido às limitações dos processadores.
Em um fator de extrema importância, como velocidade de desenvolvimento, o .NET leva grande vantagem. A sua IDE proprietária, o Visual Studio, é baseado em RAD (Rapid Application Development), aumentando a agilidade na construção de aplicações. O Visual Studio .NET inclui várias ferramentas interessantes em termos de produtividade, como por exemplo o Web Forms. Estima-se que um projeto criado do zero, leve-se de 10% a 20% menos tempo para entrar em produção quando desenvolvido em .NET.
O Microsoft .NET oferece independência de linguagem, permitindo os componentes serem escritos em VB.NET, C# e J#, por exemplo. Para fazer isto funcionar, o código-fonte nestas diferentes linguagens é traduzido para um código intermediário (análogo aos bytecodes do Java) chamado Microsoft Intermediate Language, abreviado IL. O Common Language Runtime (CLR), análogo ao JRE (Java Runtime Enviroment) do Java, interpreta o IL e traduz em código de máquina.
Com um conjunto de linguagens rodando sobre a plataforma .NET, os desenvolvedores diminuem a habilidade de compartilhar as melhores práticas, diminuindo a assertividade do compartilhamento de informações. Assim, especula-se que um conjunto de linguagens rodando em CLR pode levar a uma combinação de código espaguete que fica difícil de manter. Com a liberdade para se utilizar diversas linguagens, a aplicação torna-se mais complexa, necessitando de experts em diferentes linguagens, o que também faz aumentar o TCO e a entropia do sistema.
As duas tecnologias apresentam uma curva de aprendizado parecida, com a diferença de que o Java possui mais material para aprendizado na internet do que o .NET, que é proprietário e a principal fonte de conteúdo é o MSDN.
Analisando o último quesito, portabilidade, praticamente não há o que comparar. Como já dito na coluna anterior, o Java segue o princípio write once, run anywhere, permitindo executar as aplicações na virtual machine em praticamente qualquer ambiente. O .NET roda apenas no Windows, no seu hardware suportado, e no ambiente .NET. Há algumas implementações adicionais do .NET que rodam em outras plataformas, porém que não permitem o uso de todo o potencial do framework.
Concluindo a análise, a plataforma J2EE, possuindo uma interoperabilidade melhor, permite mais facilmente integrações com o legado através de web services e JCA (Java Connector Architecture) e uma maior facilidade de portabilidade, podendo rodar em qualquer sistema operacional. A grande vantagem do .NET é a sua incrível ferramenta de desenvolvimento, que incrementa bastante a velocidade na construção de aplicações. Porém, esta vantagem apresenta o custo das licenças de uso e de se ter uma plataforma proprietária e fechada, seguindo a iniciativa monopolística da Microsoft.
Para a escolha de qual tecnologia utilizar, deve-se analisar o que já se tem de legado e os skills da equipe que irá trabalhar no projeto, aproveitando os conhecimentos já existentes nas linguagens.
Não perca a próxima coluna, onde vamos comparar Ruby on Rails com PHP (vamos deixar o Java um pouco de lado).
* Agradeço ao funcionário Thiago Frederes pela ajuda na elaboração das idéias aqui contidas.
Comentários (14)
Jair, em 29/05/2009, 16:45
É importante lembrar que Java também permite o uso de outras linguagens sobre a JVM como o JRuby, Groovy, etc.
E também há várias opções de IDE para Java tão produtivas quanto VS .NET, como Eclipse, Netbeans e IntelliJ, que também têm funcionalidades RAD.
Gabriel, em 29/05/2009, 18:23
O nobre colega esquece o Mono, que permite rodar .NET em Linux. De qualquer forma, Perl está muito à frente de ambas as plataformas no quesito portabilidade: http://www.cpan.org/ports/
André Luiz Lehmann, em 29/05/2009, 21:45
Comparar JEE(o nome novo que a Sun deu) com ASP .NET é incabível. JEE é uma plataforma, enquanto ASP .NET é uma linguagem(ASP) que roda sobre uma plataforma(.NET).
E sobre produtividade, não há o que negar. É muito mais fácil para a Microsoft fazer uma IDE focada numa linguagem, do que deixar a merce da comunidade Java fazer uma para qualquer uma das "tecnologias" de desenvolvimento. E digo "tecnologias" porque eu não conheço nenhum linguagem que seja especificamente JEE.
Vagner Montenegro, em 04/06/2009, 15:30
Achei um pouco tendencioso as observações apesar de não concordar com a Microsoft, e antes de começar as comparações com PHP e Ruby On Rails por favor compare PHP + Algum Framework já que On Rails é um framework do Ruby, agora se for comparar PHP vs Ruby ai sim vá em frente
Pescador, em 04/06/2009, 16:00
Acho engraçado idealistas da informática louvar o open source e fazer software pra vender. Meio contraditório...
Daniel, em 04/06/2009, 17:12
Paulo, você comparou uma plataforma (J2EE) a um framwork (ASP) e comparou essa mesma plataforma a uma IDE (Visual Studio) o que faz com que vários comentários e análises estejam equivocados.
William Antônio Siqueira, em 04/06/2009, 22:16
"Acho engraçado idealistas da informática louvar o open source e fazer software pra vender. Meio contraditório..."
O que está em jogo quando se defende algo OpenSource é a liberdade, a inteligência coletiva e domínio do que se usa.
O Google é bonzinho liberando API's e ferramentas para desenvolvedores? Não! Ele tem a maior massa de desenvolvedores do mundo, como a Sun tem. A afinidade de desenvolvedores é algo muito importante! A Microsoft tem um pequeno problema com a comunidade de desenvolvedores... Lembram dos problemas que a microsoft enfrentou com desenvolvedores para Windows Mobile? E para Android, existe esse problema?
Viva Java!
Vanderlei, em 06/06/2009, 19:05
Você encapsulou suas colocações em um gráfico. Logo você deve ter realizado um estudo para expor com tanta propriedade o mesmo. tens como divulgar esse estudo, seria muito interessante analisar seus levantamentos.
Rogério Moraes de Carvalho, em 06/06/2009, 20:36
Olá pessoal,
A comparação entre as plataformas Java e .NET costuma ser polêmica e gerar debates acalorados. Na maioria das vezes, estes debates deixam a parte técnica de lado e passam a conter acusações pessoais e indelicadezas dos participantes. Como se pode notar, este debate não foi uma exceção a esta regra. Apesar de estarmos num fórum destinado a debates técnicos, a discussão foge do âmbito técnico para se tornar uma defesa quase religiosa. Com algumas exceções, cada um quer provar que a plataforma que ele utiliza, seja a plataforma Java ou a plataforma .NET, é a melhor. Por conta disto, a precisão técnica dos posts fica comprometida e acaba prejudicando a todos interessados em obter informações corretas de comparação entre as duas plataformas.
A minha intenção é somente corrigir uma série de imprecisões técnicas no artigo original “Java vs .NET”, escrito pelo Paulo Krieser. Eu não vou comentar as imprecisões dos posts de ataque ao artigo.
Para facilitar a leitura, eu estarei destacando trechos do artigo original e comentando-os na sequencia. Os trechos mais longos serão simplificados com uso de reticências (...).
Trecho do artigo original:
“Prosseguindo com a sequência de colunas sobre as comparações entre linguagens de programação, neste artigo vamos comparar o Java ao .NET.”
Comentários técnicos do trecho destacado anteriormente:
O artigo tem como objetivo prosseguir com uma sequência de colunas com comparações entre linguagens de programação. Portanto, a comparação não poderia ser entre Java e .NET, mas sim entre Java e C# ou Java e Visual Basic .NET, isto para comparar uma linguagem da plataforma Java com uma linguagem da plataforma .NET. E para o artigo ser preciso, ainda deveria informar as versões das linguagens de programação usadas na comparação. Por exemplo, a linguagem Java teve mudanças significativas na versão 5.0 (Java 5.0). Assim, como a linguagem C# teve modificações significativas na versão 2.0 (C# 2.0) e outras significativas na versão 3.0 (C# 3.0). O mesmo aconteceu com a linguagem Visual Basic .NET, atualmente denominada simplesmente Visual Basic, que já teve sucessivas versões voltadas para a plataforma .NET: Visual Basic .NET (versão 7.0), Visual Basic .NET 2003 (versão 7.1), Visual Basic 2005 (versão 8.0) e Visual Basic 2008 (versão 9.0).
No parágrafo seguinte, ao tentar evitar críticas, o autor cometeu diversos erros.
Trecho do artigo original:
“Antes que sigam as críticas, cabe esclarecer que o .NET não é uma linguagem, e sim uma plataforma da Microsoft que permite a utilização de diversas linguagens, como C#, Visual Basic, J# e ASP.”
Comentários técnicos do trecho destacado anteriormente:
Este trecho está quase perfeito tecnicamente, não fosse pela inclusão do ASP como uma linguagem de programação. Na realidade, o ASP (Active Server Pages) não é uma linguagem de programação, mas sim uma tecnologia para desenvolvimento de conteúdo Web dinâmico. Inicialmente, páginas ASP eram escritas com linguagens de script como VBScript ou JScript. Com o lançamento da primeira versão final da plataforma .NET, em fevereiro de 2002, o ASP evoluiu para o ASP.NET. Atualmente, o ASP.NET corresponde a um modelo unificado de programação que inclui serviços necessários para construir aplicações Web corporativas com um mínimo de codificação.O ASP.NET é parte do .NET Framework e na codificação de aplicações ASP.NET é possível acessar classes do .NET Framework. A codificação de aplicações Web com ASP.NET pode ser feita com qualquer linguagem compatível com o ambiente de execução (CLR - Common Language Runtime), incluindo C#, F#, Visual Basic e outras linguagens.
Trecho do artigo original:
“Vamos focar então a comparação na construção de aplicações web, utilizando J2EE e o framework ASP NET da Microsoft, que é onde as duas linguagens mais competem.”
Comentários técnicos do trecho destacado anteriormente:
Neste ponto, o autor deixa claro que não deseja comparar linguagens de programação, mas sim frameworks para desenvolvimento Web nas plataformas Java e .NET. Mesmo assim, ainda comete a seguinte imprecisão: “que é onde as duas linguagens mais competem”. Certamente, ele quis dizer: “que é onde as duas plataformas mais competem”. O nome J2EE foi utilizado até a versão 1.4. A partir da versão 5 (versão final atual), o nome foi modificado para Java EE. Porém, o Java EE não deve ser comparado diretamente com o ASP.NET. Isto porque o Java EE inclui diversos serviços que são fornecidos em outras APIs (fora do ASP.NET) dentro do .NET Framework. Por exemplo, atualmente, o desenvolvimento de uma arquitetura orientada a serviços (SOA - Service-Oriented Architecture) em .NET utiliza uma API denominada WCF (Windows Communication Foundation). Porém, o Java EE já inclui uma série de APIs que podem ser usadas para este mesmo propósito, como: JAX-WS 2.0, EJB 3.0 e JBI.
Neste caso, o autor poderia comparar recursos de um subconjunto do Java EE, como comparar Java Servlets, JSP e JSF com recursos similares do ASP.NET. Mais uma vez, esta comparação deveria apresentar as versões que estão sendo comparadas. Por exemplo, Java Servlet 2.5, JavaServer Pages 2.1 e JavaServer Faces 2.1 versus ASP.NET 3.5 SP1.
Trecho do artigo original:
“Comecemos pela questão das licenças de uso, .... Além disto, nada na Microsoft é open source.”
Comentários técnicos do trecho destacado anteriormente:
Este trecho corresponde a uma opinião pessoal do autor sem nenhuma base técnica.
A discussão de TCO é muito mais longa que o simples fato de que utilizar uma tecnologia open source é mais barato uma vez que não se gasta com licenças. Como é do conhecimento de todos, os gastos com o desenvolvimento de software envolve muito mais que gastos com licenças.
Além disto, como já foi informado em outros em posts, existem versões gratuitas do Visual Studio 2008 SP1 (versão final mais recente) disponíveis para download. Correspondem às edições Express, que podem ser baixadas no seguinte endereço: http://www.microsoft.com/express/download/. De qualquer modo, é importante ressaltar que as edições Express têm uma série de limitações com relação às versões comerciais. Como por exemplo, oferecem suporte muito limitado a refactoring, não fornecem suporte integrado a diagramas de classes, não fornecem testes unitários e diversos outros recursos importantes para auxiliar no ciclo de desenvolvimento de software. Neste ponto, as edições Express do Visual Studio 2008 SP1 ficam muito atrás das IDEs NetBeans e Eclipse, que são poderosas IDEs open source fornecidas gratuitamente para desenvolvimento na plataforma Java.
E o maior erro do autor neste parágrafo foi o seguinte: “Além disto, nada na Microsoft é open source.”. A Microsoft não somente tem diversos projetos open source, como criou um Web Site para hospedar projetos open source denominado CodePlex. O site pode ser acessado no seguinte endereço: http://www.codeplex.com/. Inclusive, diversos dos projetos open source hospedados no CodePlex tem participação do time de desenvolvimento da Microsoft. Seguem exemplos de alguns projetos open source importantes hospedados no CodePlex: ASP.NET MVC, AJAX Control Toolkit, Silverlight Toolkit, DotNetNuke, SQL Server 2008 Sample Databases e DotNetZip, isto somente para citar alguns.
Trecho do artigo original:
“No item escalabilidade, as implementações das duas plataformas provêem mecanismos de balanceamento de carga, permitindo habilitar um cluster de máquinas para servir às cargas dos usuários que forem aumentando ao longo do tempo. A grande diferença entre o J2EE e o .NET é que desde que o .NET suporta apenas Win32, um número maior de máquinas se faz necessário, comparando ao J2EE, devido às limitações dos processadores.”
Comentários técnicos do trecho destacado anteriormente:
Mais uma vez, este trecho corresponde a uma opinião pessoal do autor sem nenhuma base técnica. Sendo assim, eu somente corrigirei o seguinte erro: “o .NET suporta apenas Win32”.
Atualmente, a plataforma .NET está na versão 3.5 SP1.
O Microsoft .NET Framework 3.5 Service Pack 1 (SP1) suporta as seguintes arquiteturas de processador:
• x86
• x64
• ia64 (64-bit Intel Itanium architecture) (somente suportada com o Windows Server 2008)
O Microsoft .NET Framework 3.5 Service Pack 1 (SP1) suporta os seguintes sistemas operacionais:
• Microsoft Windows XP
• Microsoft Windows Server 2003
• Windows Vista
• Windows Server 2008
Informações mais detalhadas podem ser encontradas no documento “Microsoft .NET Framework 3.5 Service Pack 1 (SP1) Readme”, disponível no seguinte endereço: http://download.microsoft.com/download/A/2/8/A2807F78-C861-4B66-9B31-9205C3F22252/dotNet35SP1Readme.htm.
Trecho do artigo original:
“Em um fator de extrema importância, como velocidade de desenvolvimento, o .NET leva grande vantagem. A sua IDE proprietária, o Visual Studio, é baseado em RAD (Rapid Application Development), aumentando a agilidade na construção de aplicações. O Visual Studio .NET inclui várias ferramentas interessantes em termos de produtividade, como por exemplo o Web Forms. Estima-se que um projeto criado do zero, leve-se de 10% a 20% menos tempo para entrar em produção quando desenvolvido em .NET.”
Comentários técnicos do trecho destacado anteriormente:
Outro trecho com uma opinião pessoal do autor sem nenhuma base técnica.
A questão de o Visual Studio ser mais produtivo que as IDEs de Java é bastante discutível. Na realidade, a discussão não é tão simples assim. Qualquer estimativa que não leve em consideração as características do projeto de software a ser desenvolvido será uma mera especulação sem a menor credibilidade.
Comparações de produtividade entre IDEs deve isolar e comparar recursos equivalentes individualmente.
Somente para citar um recurso, a última versão do IDE do NetBeans (6.5.1) tem um suporte muito maior a refactoring que a última versão do Visual Studio (2008 SP1). E a última versão do IDE do Eclipse (3.4.2 - Ganymede) ainda supera o NetBeans (6.5.1) neste quesito. Certamente, refactoring é um recurso essencial para aumentar a produtividade em projetos corporativos com arquiteturas complexas. Além disto, os refactorings do Eclipse são projetados para sugerir melhores práticas de programação orientada a objetos, superando o Visual Studio em alguns refactorings individuais.
Trecho do artigo original:
“O Microsoft .NET oferece independência de linguagem, permitindo os componentes serem escritos em VB.NET, C# e J#, por exemplo. Para fazer isto funcionar, o código-fonte nestas diferentes linguagens é traduzido para um código intermediário (análogo aos bytecodes do Java) chamado Microsoft Intermediate Language, abreviado IL. O Common Language Runtime (CLR), análogo ao JRE (Java Runtime Enviroment) do Java, interpreta o IL e traduz em código de máquina.”
Comentários técnicos do trecho destacado anteriormente:
Este trecho está quase totalmente preciso tecnicamente.
Houve apenas um pequeno equívoco no seguinte trecho: “O Common Language Runtime (CLR), análogo ao JRE (Java Runtime Enviroment) do Java, interpreta o IL e traduz em código de máquina.”. Na realidade, o Common Language Runtime (CLR) é análogo à Java Virtual Machine (JVM), não ao JRE. Além disto, JRE significa “Java SE Runtime Environment” e não “Java Runtime Environment”. O JRE é análogo a uma parte do .NET Framework, pois ele comporta o ambiente de execução Java e um conjunto de bibliotecas de classes com os recursos do Java SE.
É importante ressaltar que o ambiente de execução da plataforma .NET (CLR - Common Language Runtime) foi projetado desde o início para suportar múltiplas linguagens de programação, enquanto que o ambiente de execução da plataforma Java (JVM - Java Virtual Machine) inicialmente foi projetada somente para suportar a linguagem Java. Porém, atualmente, várias linguagens foram portadas para a plataforma Java. Somente para citar algumas: JRuby (uma implementação da linguagem de programação Ruby), Jython (uma implementação da linguagem de programação Python), Scala, Clojure (dialeto Lisp) e Groovy (linguagem de scripting). Atualmente, o JavaFX Script é a linguagem de scripting que está mais em evidência na plataforma Java, pois corresponde à iniciativa da Sun (recentemente adquirida pela Oracle) para o desenvolvimento de aplicações RIA (Rich Internet Application).
Trecho do artigo original:
“Com um conjunto de linguagens rodando sobre a plataforma .NET, os desenvolvedores diminuem a habilidade de compartilhar as melhores práticas, diminuindo a assertividade do compartilhamento de informações. Assim, especula-se que um conjunto de linguagens rodando em CLR pode levar a uma combinação de código espaguete que fica difícil de manter. Com a liberdade para se utilizar diversas linguagens, a aplicação torna-se mais complexa, necessitando de experts em diferentes linguagens, o que também faz aumentar o TCO e a entropia do sistema.”
Comentários técnicos do trecho destacado anteriormente:
A questão de uma plataforma suportar diversas linguagens de programação, não quer dizer que você é obrigado a desenvolver sistemas usando as muitas linguagens disponíveis. E, se fosse assim, este não seria um privilégio da plataforma .NET, uma vez que atualmente a plataforma Java também suporta diversas linguagens, como pode ser constatado nos meus comentários anteriores.
O uso de diversas linguagens em um projeto de um sistema certamente dificulta a manutenção do mesmo, uma vez que exige uma equipe com integrantes com conhecimentos de mais de uma linguagem ou divisões da equipe em grupos com conhecimentos de linguagens específicas. No último caso, cada integrante com conhecimento de uma única linguagem somente poderia dar suporte aos componentes desenvolvidos naquela linguagem.
Mas, a habilidade de utilizar melhores práticas em projetos de software não tem nada haver com o suporte da plataforma a múltiplas linguagens. O que importa é a capacidade da equipe (conhecimento técnico) para desenvolver uma arquitetura flexível e robusta utilizando-se boas práticas de programação orientada a objetos. Tanto a plataforma Java quanto a plataforma .NET são robustas para o desenvolvimento sistemas com ótimas arquiteturas usando padrões de projeto de forma correta, quanto são passíveis do desenvolvimento de sistemas com código “espaguete” utilizando-se péssimas práticas e o uso errado de padrões de projeto.
Trecho do artigo original:
“As duas tecnologias apresentam uma curva de aprendizado parecida, com a diferença de que o Java possui mais material para aprendizado na internet do que o .NET, que é proprietário e a principal fonte de conteúdo é o MSDN.”
Comentários técnicos do trecho destacado anteriormente:
Na realidade, tanto a plataforma Java quanto a plataforma .NET possuem uma vasta documentação de qualidade disponível. Muito mais documentação disponível que qualquer um de nós é capaz será capaz de estudar durante todas as nossas vidas.
Existem diversas grandes outras fontes de conteúdo sobre a plataforma .NET além do MSDN.
Apenas para citar algumas:
• TheServerSide.NET - Your Enterprise .NET Community (http://www.theserverside.net/)
• The Code Project (http://www.codeproject.com/)
• The Official Microsoft ASP.NET Site (http://www.asp.net/)
• The Official Microsoft IIS Site (http://www.iis.net/)
• WindowsClient.NET (http://windowsclient.net/)
• Silverlight (http://silverlight.net/)
• Mix Online (http://visitmix.com/)
• Channel 10 (http://on10.net/)
Trecho do artigo original:
“Analisando o último quesito, portabilidade, praticamente não há o que comparar. Como já dito na coluna anterior, o Java segue o princípio write once, run anywhere, permitindo executar as aplicações na virtual machine em praticamente qualquer ambiente. O .NET roda apenas no Windows, no seu hardware suportado, e no ambiente .NET. Há algumas implementações adicionais do .NET que rodam em outras plataformas, porém que não permitem o uso de todo o potencial do framework.”
Comentários técnicos do trecho destacado anteriormente:
Na minha visão, este é o parágrafo mais preciso de todo o artigo.
No quesito portabilidade, a plataforma Java sem dúvidas é a melhor escolha. Afinal de contas, a plataforma Java foi desenvolvida desde o início para suportar múltiplas plataformas. Tecnicamente, a plataforma .NET tem total condições de ser portada para múltiplas plataformas exatamente como a plataforma Java. Porém, por enquanto, a Microsoft não demonstrou o interesse de portar integralmente .NET para outras plataformas além do Windows. Inicialmente, a Microsoft forneceu uma implementação de código compartilhado denominado Shared Source Common Language Infrastructure (SSCLI), de uma pequena parte do .NET Framework. E licença não permitia uso comercial do código compartilhado. O SSCLI rodava em Windows, FreeBSD (4.7 ou superior) e Mac OS X 10.2. A última versão do SSCLI (2.0) foi lançada em março de 2006 e continha um subconjunto do .NET Framework 2.0. Diferente da versão anterior, a versão 2.0 somente era suportada no Windows XP SP2. Enquanto o Windows dominar o mercado de desktops, dificilmente a Microsoft portará .NET para outras plataformas.
Atualmente, o projeto de maior sucesso para portar .NET para outras plataformas é o Projeto Mono. Atualmente, o projeto Mono é mantido pela Novell, está na versão 2.4 e roda em sistemas operacionais Linux, Mac OS X, BSD e Windows, incluindo processadores com arquitetura x86, x64, ARM, s390, PowerPC e outros. Existe também uma IDE open source denominada MonoDevelop 2.0, que auxilia no desenvolvimento de aplicações desktop e ASP.NET em Linux. Maiores informações podem ser encontradas no seguinte endereço: http://www.mono-project.com/.
Trecho do artigo original:
“Concluindo a análise, a plataforma J2EE, possuindo uma interoperabilidade melhor, permite mais facilmente integrações com o legado através de web services e JCA (Java Connector Architecture) e uma maior facilidade de portabilidade, podendo rodar em qualquer sistema operacional. A grande vantagem do .NET é a sua incrível ferramenta de desenvolvimento, que incrementa bastante a velocidade na construção de aplicações. Porém, esta vantagem apresenta o custo das licenças de uso e de se ter uma plataforma proprietária e fechada, seguindo a iniciativa monopolística da Microsoft.”
Comentários técnicos do trecho destacado anteriormente:
A melhor interoperabilidade depende de análises específicas. Por exemplo, dizer que Java EE possui uma melhor integração com legado é bem questionável. Se o legado for composto por componentes legados da plataforma Windows, como componentes COM/COM+, é bem provável que a plataforma .NET forneça um suporte superior à plataforma Java. Isto porque, atualmente, a plataforma .NET é completamente voltada para a plataforma Windows, enquanto a plataforma Java deve se preocupar em rodar nos mais diferentes sistemas operacionais e nas mais diferentes arquiteturas de processador.
A integração por intermédio de XML Web Services e RESTful Web Services (nova tendência) é amplamente suportada pela plataforma .NET 3.5 SP1 (WCF 3.5 SP1) assim como pelas plataforma Java no Java EE 5 (JAX-WS 2.0).
A questão de licença, tão citada pelo autor como uma desvantagem da plataforma .NET, também é bem relativa. Não é somente a Microsoft que cobra licenças em servidores de aplicações. Na plataforma Java EE, alguns dos servidores de aplicação mais robustos também possuem taxas de licenciamento, e altas, como por exemplo:
• IBM WebSphere Application Server V7 (http://www-01.ibm.com/software/webservers/appserv/was/)
• Oracle WebLogic Server 10g Enterprise Edition (http://www.oracle.com/appserver/weblogic/enterprise-edition.html)
Observe que a plataforma Java já não é tão democrática como antigamente. Afinal de contas, recentemente, a Oracle comprou alguns dos seus principais concorrentes na plataforma Java: BEA (que tinha o WebLogic, que hoje pertence à Oracle) e, mais recentemente, a Sun Microsystems (criadora da linguagem e da plataforma Java). Ainda bem que ainda existe a IBM como um competidor de peso para disputar com a Oracle.
Observe que até mesmo o poderoso servidor de aplicações open source JBoss foi adquirido pela Red Hat. Para obter suporte profissional ao JBoss Application Server 5.1.0 você pode desembolsar muito mais grana que adquirindo uma licença e suporte no Windows Server 2008, com o servidor de aplicações .NET embutido.
Ou seja, o autor do artigo sugere que na plataforma Java os softwares são open source e isento de taxas de licenciamento, enquanto a Microsoft sempre quer ganhar dinheiro com a plataforma .NET. Mas, as coisas não sem bem deste modo. Principalmente, quando estamos falando de aplicações de missão crítica que necessitam de um suporte profissional por parte dos fornecedores de soluções. Oracle, IBM, Red Hat e Microsoft, somente para citar algumas, todas querem ganhar dinheiro com seus produtos, não interessa se são voltados para a plataforma Java ou para a plataforma .NET.
Conclusão
O autor se demonstrou extremamente tendencioso e completamente leigo na plataforma .NET. Mesmo na plataforma Java, ele mostrou estar com os conhecimentos bastante defasados.
Eu acho que uma comunidade técnica sempre espera encontrar artigos com embasamento técnico, que permita fazer uma reflexão. Afinal de contas, opiniões pessoais sem fundamentos não acrescentam muito para nenhum participante da comunidade.
Abraços a todos,
Rogério Moraes de Carvalho
Rogério Moraes de Carvalho, em 07/06/2009, 13:41
Relendo os meus comentários, eu percebi que cometi três pequenos erros.
Seguem as correções.
Eu cometi um erro na versão do JavaServer Faces, tendo digitado "JavaServer Faces 2.1" ao invés de "JavaServer Faces 1.2". A versão final atual de JSF no Java EE 5 é a versão 1.2.
Num trecho eu escrevi "...é capaz será capaz..." ao invés de somente "será capaz". Segue o trecho corrigido.
"Na realidade, tanto a plataforma Java quanto a plataforma .NET possuem uma vasta documentação de qualidade disponível. Muito mais documentação disponível que qualquer um de nós será capaz de estudar durante todas as nossas vidas."
No final, eu cometi um pequeno erro de concordância no seguinte trecho:
"Ou seja, o autor do artigo sugere que na plataforma Java os softwares são open source e isento de taxas de licenciamento, enquanto a Microsoft sempre quer ganhar dinheiro com a plataforma .NET."
O correto é "isentos" ao invés de "isento".
Segue o trecho corrigido:
"Ou seja, o autor do artigo sugere que na plataforma Java os softwares são open source e isentos de taxas de licenciamento, enquanto a Microsoft sempre quer ganhar dinheiro com a plataforma .NET."
Abraços,
Rogério Moraes de Carvalho
Paulo Krieser (Krieser IT Solutions), em 09/06/2009, 12:25
Pessoal,
Agradeço os comentários. Vou escrever a próxima coluna em resposta a eles.
Raphael, em 09/06/2009, 23:12
Esse artigo e o articulador estão alguns anos no passado. Quem acha que uma aplicação java é tão mais custosa de ser produzida que .net nunca viu Grails, Groovy, SwingBuilder, JavaFX, Griffon, etc...
Sergio Brito, em 13/07/2009, 18:45
Senhores,
Parabenizo o autor pela iniciativa de comparar 2 linguagens, e critico severamente os colegas que apenas apontam defeitos, sem se darem ao trabalho de reescrever o artigo da maneira como acham correto. Ao Sr. Rogério, parabéns pela iniciativa, mas sugiro que resuma o texto da próxima vez.
Abraços,
Ricardo
Cleber Machado, em 07/09/2009, 03:22
Parabéns pelo Artigo é uma ótima iniciativa.
Mais tem alguns problemas sérios:
O Titulo está errado "Escolhendo a Linguagem: Java vs .NET" deveria ser Java vs C++,C#, Basic ou ASP. O que também estaria errado porque ambas as linguagem tem as funções básicas(+,-,if) logo pela Hipótese de Church(Teoria da Computação) tem o mesmo Poder Computacional.(se provar que é diferente refuta Hipótese de Church e ganha o Premio no Nobel). Poderia ser "Escolhendo a Plataforma: Java ou .NET" mais também não chegaríamos a lugar nenhum porque são plataforma muito amplas é necessário escolher uma implementação de cada para comparar.
Para fazer um artigo assim você tem fazer referencia ao caso em questão.
ENVIE UM COMENTÁRIO
Paulo Krieser Paulo Krieser é diretor executivo da Krieser IT Solutions, empresa especializada no desenvolvimento de aplicações corporativas nas mais diversas tecnologias.
