Comparación entre Java y Visual Studio

"Para muchos desarrolladores de java se les torna complejo realizar un cambio de lenguaje, o muchas veces por desconocimiento desechan algunas opciones, en el siguiente artículo veremos un análisis comparativo entre java y las tecnologías .Net."

Java y Visual Studio no se compilan a código maquina si no que se compilan a un formato intermedio, aunque parezca una semejanza en este punto nace la primera gran diferencia, ya que estas dos implementaciones difieren fundamentalmente en su filosofía. Comparar Common Language Runtime con la máquina virtual de Java sólo resulta razonable hasta cierto punto, ya que sus objetivos en cuanto a la arquitectura son muy diferentes.

Sun Microsystems promueve un programa de marketing llamado 100% Pure Java que resulta ciertamente muy adecuado cuando lo que se persigue es la portabilidad del código y la transparencia del sistema operativo subyacente. Sin embargo, muchos servidores de aplicaciones Java de terceros crean una ventaja competitiva al utilizar de forma muy acertada las llamadas a funciones de "C" (a través de Java Native Interface o JNI) en servicios de valor añadido de sus sistemas operativos host, que no expone la plataforma de aplicaciones Java (la biblioteca de clases Java). Las llamadas a la plataforma principal constituyen el único mecanismo viable para utilizar la funcionalidad base que sólo se presenta a través de una interfaz nativa.

La máquina virtual de Java es una auténtica "máquina virtual" cuyo principal objetivo es abstraer (hacer virtual) el sistema operativo subyacente y proporcionar un entorno de desarrollo idealizado (no necesariamente ideal, sino idealizado). También está íntimamente unida a la API, la plataforma de aplicaciones Java, en la que los servicios los proporciona la implementación de la máquina virtual. Independientemente de dónde ejecute el código Java compilado, lo ejecutará dentro del contexto de la máquina virtual y lo vinculará ostensiblemente con las API de la plataforma Java proporcionadas.

El nombre de .NET Common Language Runtime es muy acertado, ya que se utiliza más como tiempo de ejecución de lenguaje que como máquina virtual. Aunque no tiene problemas para abstraer los aspectos del hardware subyacente mediante el uso de un lenguaje intermedio, cuando CLR se combina con la biblioteca de API de .NET Framework, se vincula a la plataforma subyacente, Windows. CLR proporciona todos los servicios de la plataforma Windows a cualquier lenguaje habilitado para .NET.

Otra diferencia entre estas dos herramientas es la seguridad de sus aplicaciones, puesto que en .Net, además de las API utilizadas para la criptografía, las cookies de seguridad y la autenticación, existe un mecanismo enriquecido y extensible para la asignación de distintos niveles de permisos a conjuntos de usuarios diferentes en función del origen del código. Por ejemplo, todo el código de Microsoft se puede considerar seguro. Se puede otorgar (o denegar) acceso de lectura y escritura sobre determinados recursos (tales como la pantalla o el directorio temporal) al código que proceda de una URL específica. Asimismo, se pueden marcar algunas aplicaciones para especificar que necesitan determinados permisos (por ejemplo, el acceso al sistema de archivos). Si estos permisos no se encuentran disponibles, la aplicación no se cargará. Puesto que la comprobación de seguridad se realiza en el momento de la carga, no es necesario que el desarrollador escriba en la aplicación lógica para la detección de errores de seguridad. Todo este proceso se administra a través de una nueva tecnología, llamada "seguridad de acceso al código", que funciona con código cargado desde Internet o el equipo local, lo que hace de Visual Studio mas seguro en sus aplicaciones respecto a Java .

El sistema de control de versiones de Visual Studio .Net es más robusto que el de Java. En Java, si se instalan dos versiones de la misma clase, el tiempo de ejecución sólo cargará la primera clase que encuentre en la ruta de acceso de clases, sin tener en cuenta la versión. En cambio, Visual Studio .Net se ha diseñado para ofrecer una amplia compatibilidad con todo tipo de versiones. Con la ejecución página tras página, se pueden cargar y ejecutar a la vez varias versiones diferentes de la misma clase. Cada aplicación puede seleccionar su mecanismo de enlace: enlazar a una versión específica de una biblioteca de clases, la más reciente, o bien, a una versión que se encuentre en una ubicación específica. Asimismo, se pueden aplicar directivas por equipos para reemplazar o volver a definir más adelante el control de versiones. Este control de versiones se aplica también a los lenguajes de programación.

La característica de Visual Studio .Net que realmente destaca sobre las de Java es la capacidad para definir el rendimiento y el comportamiento de las aplicaciones. Las unidades principales de creación de aplicaciones se han diseñado para ofrecer escalabilidad y un rendimiento elevado. Por ejemplo, con el acceso a datos desconectado de ADO.NET, se pueden realizar en memoria un número mayor de funciones de datos, lo que en JDBC (Java Database Connectivity) exige un recorrido de ida y vuelta a la base de datos. Además, la arquitectura de la aplicación .NET se ha diseñado para que ésta sea más rápida. Por ejemplo, las páginas Web ASP.NET ofrecen un rendimiento altamente mejorado en comparación con las páginas Active Server (ASP), las páginas Java Server Pages (JSP) y los lenguajes de secuencias de comandos incrustados HTML. Si lo comparamos con la plataforma Java, el rendimiento de .NET resulta mejor no sólo en escenarios de un único usuario, sino también en escenarios multiusuario.

Otra diferencia fundamental es la portabilidad que nos proporciona Java, ya que a diferencia de .Net una aplicación construida en Java se puede ejecutar en distintos tipos de Sistemas Operativos sin ningún problema.