El otro día, estaba por terminar mi día de trabajo en equipo, cuando escucho algunas palabras fuertes llegando desde otro equipo:
“Recórchilis!”
”Cáspita!”
Bueno, eran un poco más fuertes… ;-)… Y estaban dedicadas a Java. Dos programadores .NET estaban tratando de armar un programa Java que se comunicara con un servidor web, servicio REST supongo, con autenticación. Y estaban luchando con la librería y el lenguaje Java.
Eso lo he visto en varios desarrolladores .NET que en algún momento tienen que trabajar en Java. ¿Es así? ¿Es Java más difícil de programar, más “convoluted”?
Recuerdo aquel viejo “sketch” de Les Luthiers, cuando Yugurtu Ungue le escribe desde EE.UU. a su tío en Africa: “Trabajo en una serpiente gigante que va por un camino de metal” y el tío contesta “Ah! Es lo más parecido a un tren que escuché en mi vida!” Ver
http://www.youtube.com/watch?v=QfB7N_z7dJM
http://www.youtube.com/watch?v=1WqMOXXcQ9c
http://www.youtube.com/watch?v=x2aRiZCM0i8
;-)
Algo así digo yo cuando me describen a .NET: “Es lo más parecido a Java que escuché en mi vida!”. ;-)
Java aparece al público en 1995 de la mano de Sun. Y fue el primer lenguaje/tecnología que llevó a las masas: objetos con garbage collector, una amplia librería de clases, y una máquina virtual que puede ejecutarse en distintos sistemas, sin necesidad de recompilar (fuera las incompatibilidades de portar int de C de Unix a otro Unix, por diferencias de tamaño). Y eso fue bueno: yo nunca llegué a tocar VB6, y me libré de usar Threaded Apartment Model, COM+, y esa cosa trasnochada que eran los recordset desconectados en ADO. Eso sí era “convoluted”!
Lo que pasó, es que Microsoft consiguió mejorar todo eso, con la llegada de .NET, con un mejor tooling inicial y una librería de clases “afiatada” luego de la experiencia de Java. Hasta hizo pruebas de usabilidad y mejoró la librería (un poco) en la siguiente versión. Por ejemplo, aparecieron File.ReadAllLines al ver que los programadores .NET tenía dificultad en entender los streams y readers (justamente, ese era uno de los temas que el equipo que mencioné arriba estaba luchando, creando InputStream, Reader, BufferedReaders y demás en Java). Mientras tanto, Java sufría las especificiaciones J2EE de Sun: parecía que las había escrito el “enemigo”. A Java lo salvó la comunidad open source: desde Tomcat hasta Hibernate, hasta el notable Eclipse. A .NET lo salvó Microsoft: siguiendo un crecimiento natural, mientras que en Java todavía estamos esperando la llegada de closures naturales en el lenguaje. Hasta la movida de Microsoft de publicar C# y .NET como standard, permite el nacimiento del proyecto Mono, y hoy tenemos .NET multiplataforma.
A Java lo salvan también IBM con su apoyo a Eclipse, la fundación Apache, Spring Framework, Hibernate (vean cómo influyó en EJB 3, demasiado tarde) y otros proyectos de código abierto. Es gracias a esos movimientos que tenemos unas IDE open source en Java: Eclipse. Tal vez su gran característica (flexibilidad, todo es un plugin) conspira con la experiencia Out of the box que nos da Visual Studio. Cada Eclipse de cada máquina/equipo, en una consultora, es un Eclipse distinto ;-). Otro caso, Jboss Application Server, con microkernel: con un problema (su herencia de EJB, JEE), tan flexible, que termina siendo un mundo complicado comparado con las tecnologías servidoras que tenemos en .NET.
Pero vean algunas cosas: eso que pasó en Java, la aparición temprana de tantos frameworks y librerías, también hace que hoy, un proyecto Java, es un modelo para armar. Tantas opciones (y además dispares) agrega complejidad. Vean cómo todo esto propulso la aparición de Spring Framework (para poder ligar multitud de librerías dispares) y ese agitador de discos duros que se llama Maven. Muchos aman a Maven, un automatizador de builds y manejador de proyectos, porque soluciona un problema que NO TENDRIA QUE SER PROBLEMA: manejar la complejidad. Yo sigo pensando que Ant es mucho más entendible. Vean que tanto Spring Framework como Maven no han tenido necesidad de ser usados en .NET.
Vean cómo la complejidad de especificaciones como los Web Services han sido resueltos de distinta forma por Java/Sun y .NET/Microsoft. Mientras que tenemos WCF (complicado de configurar, pero empaquetado simplemente) en .NET, del lado de Java tenemos DECENAS de .jars (librerías) para construir la librería Metro.
Espero que NuGet no agregue esa complejidad de opciones en .NET: por lo menos, lo que me trae NuGet queda dentro de la solución que manejamos, y al contrario de Maven, se ocupa de ese solo tema: ser un package manager.
Hoy hay una comunidad de Java altamente activa, pero algo golpeada por la compra de Sun por Oracle. Hay también una gran actividad en el soporte y difusión de lenguajes dinámicos sobre la JVM, notablemente Scala, Clojure y Groovy. Hay algo menos en .NET (donde Microsoft “mató” IronRuby, IronPhyton, esperemos qué hace con Javascript). Pero hay una gran comunidad de proyectos de código abierto, o directamente consumibles via NuGet.
No tengo una conclusión para el post, mas que un resumen: Java es el padre de gran parte de .NET, Java tuvo una historia accidentada, tiene una comunidad altamente activa, pero su futuro es incierto de la mano de Oracle. Hay dinamismo en pasar de Java a JVM + lenguajes. .NET sigue su futuro, en aplicaciones servidoras? (¿qué pasará con las interfaces de usuario?). Java y tooling es más áspero o complejo en el lado de Java que del lado de .NET.
Y si Uds. trabajan en .NET, es gracias a que en la historia apareció Java.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez