Enfrentado de nuevo a la tarea de revisar un producto software, ¿quién habrá de revisar mis propias intenciones, carencias o sarcasmos sibilinos? ¿Quién impone los criterios de revisión? Pues yo, naturalmente, y en el presente caso decido que serán los de uso y adecuación práctica. Y -¿por qué no?- me permitiré también algún insulto solapado y más de un elogio desmedido. Y es que Java es a la vez buen paraguas y apropiado chirimiri.

EMPEDRADO COMO EL INFIERNO

Un producto se entenderá tanto mejor cuanto mejor se adecue al fin para el que fue diseñado. Claro que... ¿cuál es éste? Si lo que se pretende con Visual J++ es dotar al programador [1] de una herramienta que le ayude a generar programas de calidad industrial para su uso en entornos no domésticos, indudablemente nos hemos equivocado de lenguaje, de herramienta, de año y hasta de dimensión. Oh, discúlpenme: Java me parece genial (precisamente por su ausencia de genio), y Microsoft Visual J++ me gusta bastante (¡Quién lo diría!). El problema es que todavía no existen definiciones definitivamente estables del entorno tecnológico Java ni del lenguaje como para permitir grandes inversiones en productos y componentes que fácilmente quedarán obsoletos o inoperantes en futuros lanzamientos comerciales. Por ejemplo: ¿Cómo podría yo aconsejar a una empresa que invirtiera en la creación de componentes corporativos Java cuando probablemente en el plazo de pocos meses pueda comprar esos mismos componentes, ya personalizables, por un costo decididamente inferior al de mi propia minuta de consultor? ¿Cómo abocar los esfuerzos y dineros de una compañía hacia JDK 1.1 cuando se espera JDK 1.2? Oh, sí, la investigación es fundamental, y las estructuras arquitectónicas también lo son, pero tan sólo en proyectos de al menos 1,5 años de duración, situados en una bamboleante cresta tecnológica y precisados de un particular esfuerzo crítico y de criba [2]. Pero, esperen: ¿Quiere esto decir que no les aconsejo Java como lenguaje de programación? ¡Vaya! ¡Me expliqué mal! Les aconsejo encarecidamente que adopten Java como lenguaje de programación (Smalltalk es demasiado bueno, C++ es sólo para cierto tipo de programadores serios, mientras que Visual Basic es para otro cierto tipo de programadores); que lo adopten y lo mimen, celosos de su futuro, caritativos con sus defectos y ecuánimes en sus comparaciones posibilistas; que se agarren a él, en definitiva, como única tabula rasa aunque sea un clavo ardiendo. Lo que quiero al fin insuflarles es que... ¡Atención a la medición de sus posibilidades! Sin duda Microsoft Visual J++ conseguirá programas que satisfarán el ego de sus papás, pero que difícilmente explicarán la inversión empresarial en tiempo, dinero y potencial estratégico. Les vengo diciendo hace tiempo que los que no se enganchen ahora al carro Java necesitarán en breve de guías que los conduzcan a través de los procelosos y cada vez más tupidos APIs de la plataforma. Inviertan, pues, en tiempo personal, en esfuerzo volitivo y en satisfacción técnica. Pero, en fin: volvamos a la intención del producto que nos ocupa. Si, contrariamente a lo expuesto, lo que se intenta conseguir es la mentalización del usuario respecto de la adecuación y capacitación tecnológica de Microsoft en todos los frentes, cabría afirmar: "Con Microsoft, como con las croquetas de restaurante, hay que tragar y no indagar", parafraseando al original de Sacha Guitry referido a las mujeres.

J++ 1.1 VERSUS JDK 1.1

Nada hay en común entre ambas numeraciones, a no ser el deseo de Microsoft de mitigar las diferencias conceptuales entre ambos productos. ¿Productos? ¡Oh sí! Se trata de productos: Visual J++ es un entorno de programación comercial, miembro de una familia de herramientas de programación que hacen gala de una interfaz básica quasi-común (Visual Studio); JDK es, por otro lado, un producto tecnológico de JavaSoft que comprende máquina virtual, intérprete, compilador, clases, etc. JDK no es, por tanto, un lenguaje, sino el entorno tecnológico que a la vez lo aprisiona y extiende. Claro que Visual J++ es, por su naturaleza, un producto dependiente de las posibilidades, restricciones y licencias de uso del JDK: las sucesivas versiones de esta plataforma Java tenderán, supuestamente, a forzar a los licenciatarios a actualizar sus productos dependientes, de forma que es de esperar una rápida adecuación de éstos a la tecnología madre. Con todo, la pregunta subsiste: ¿se ajusta Visual J++ 1.1 a JDK 1.1? En tres palabras: no, no, no. Pero, esperen, repetiré la pregunta: ¿Posee Visual J++ 1.1 alguna de las características de JDK 1.1? Err... pues... mm... siendo flexible... sí. Eh, eh, noto alguna reticencia del lector receloso. Pero es que creo que tal y como se espera que el diccionario de castellano de Microsoft Word se ajuste al de la Real Academia Española, igualmente se espera que un entorno de programación Java se ajuste al lenguaje Java. Esperen, esperen: yo no tengo inconveniente en comprar un diccionario de español del medievo, pero preferiría una versión del idioma que pudiera comprender hasta un político: una versión actual, en definitiva. Ah, aquel directivo de Microsoft, secundado por varios agentes armados de Visual Studio y polos disuasorios, me plantean dos arrebatos supuestamente irrebatibles:

• JDK 1.1 todavía estaba en versión beta cuando terminamos Visual J++ 1.1
• El lenguaje Java no ha cambiado, en esencia, del JDK 1.0 al JDK 1.1. Únicamente se han añadido características dependientes del modelo de componentes de Java Beans que hace tiempo están disponibles mediante ActiveX y que, por tanto, no nos merecen demasiada atención.

Bueno, JDK 1.1 pasó por tres versiones beta hasta que recientemente se produjo su lanzamiento comercial, con anterioridad al lanzamiento de Visual J++, lo que hubiera aconsejado su revisión y un lógico aplazamiento de la comercialización del producto de Microsoft. Pero se trata de que la asunción "no se debe trabajar con versiones beta" invalidaría el uso de la práctica totalidad de productos actuales de programación no trivial. Por otro lado, en el caso del JDK, los documentos han precedido notablemente al código, de forma que Microsoft sí debería haber generado un nicho lingüístico de fácil actualización. Pero es que las cuitas del JDK 1.1 no se centran sólo en los añadidos, sino también en las modificaciones al lenguaje, a sus construcciones, a sus bibliotecas, a sus moda operandi. La situación no es tan simple: el desprevenido programador que intente compilar con Visual J++ 1.1 cualquier código de ejemplo del JDK 1.1 se encontrará con una miríada de errores: el nuevo soporte de Java para clases anidadas [3], el cambio de la AWT que origina que ninguna de las ventanas construidas con JDK 1.0.X pueda cerrarse, los nuevos APIs de Introspección, etc., etc., etc. La declaración defensiva respecto de ActiveX sugiere, por otro lado, una pregunta del tipo "¿Con Java o COMmigo? Ni contigo ni sin ti, cabría responder, remedando el famoso proverbio griego sobre las mujeres.

APPLETS

Al lector doméstico puede interesarle saber que los nuevos applets dependientes de JDK 1.1 no podrán ejecutarse, normalmente, en los actuales paginadores (MS Internet Explorer, Navigator, etc.) debido a que utilizan el nuevo esquema de eventos, nuevas etiquetas HTML, características nuevas del lenguaje, etc. La razón es que tales paginadores están indeleblemente enlazados a bibliotecas de clases Java instaladas con el propio programa.

Al lector profesional le interesará constatar que los applets en absoluto tienen relevancia en el nuevo modelo de componentes Java, pero que, no obstante, en el BDK se ofrecen envoltorios ( wrappers ) para que un Java Bean pueda ejecutarse como un applet y también que para un applet opere como un Java Bean. Poco que ver con Visual J++, por tanto.

REVISIÓN DIFERENCIAL

Al grano: ¿Cuáles son las características diferenciales de Visual J++ 1.1 respecto de la anterior versión 1.0?

• Más y mejores posibilidades de personalización del entorno, como consecuencia lógica de la integración de lenguajes de programación en la familia Visual Studio.
• Posibilidad de grabar macros en VBScript que podrán ser añadidas al menú o a una barra de herramientas del entorno.
• Adición de acciones post-construcción (post-build), de manera que pueden especificarse los pasos a seguir tras la construcción final de una aplicación o componente, como, por ejemplo, la publicación en un servidor web de un applet dado tras su construcción definitiva.
• Mayor facilidad para crear componentes ActiveX mediante el ActiveX Wizard, que puede ocuparse por nosotros de convertir una clase Java en un objeto COM, de crear el correspondiente fichero IDL y el identificador global único CLSID, de registrar la clase como un ActiveX en el sistema, y de crear la biblioteca de tipos a partir de la especificación IDL, para finalmente reseñarnos el código a añadir al código Java de forma que tras la recompilación podamos usar el nuevo componente ActiveX recién creado.

• Acceso mejorado a bases de datos mediante DAO (Data Access Objects) y RDO (Remote Data Objects), para lo que el entorno provee un elemental asistente (Database Wizard) para la creación de proyectos de acceso a RDBMSs bien directamente (mediante DAO) bien a través de una fuente de datos ODBC (mediante RDO).

• El proyecto resultante genera la aplicación que se muestra en la Figura 3,donde a la conexión básica a los datos se han añadido los típicos botones "primero", "anterior", "posterior" y "final" de manejo de registros, así como los de "grabar", "añadir", "borrar", "releer" y un último para "salir". Mi impresión es, con todo, que se trata de generar un esqueleto de código que sirva al principiante para comprender algunos automatismos y que, además, le inste a modificarlo y aun a crearlo desde cero.

JDBC: SIGLAS QUE NO SON SIGLAS [4]

Visual J++ no permite operar con JDBC. Punto. JDBC es un API programático de acceso a bases de datos, incluido en JDK 1.1 como parte de la plataforma y significado por una biblioteca de clases adecuada. Visual J++ soporta JDBC hasta el punto que parece soportar cualquier clase Java. Pero este es un punto muy pequeño (no nos olvidemos de JDK 1.1).

EL RIESGO SOLAR: FACTORES DE PROTECCIÓN

La brutalidad con que desde Sun y su entorno se examina la tecnología Microsoft me parece pedante, excesiva, malsana y cerril. ¿O me equivoqué con los nombres? Quizás sea desde Microsoft hacia Sun. Lo cierto es que el embrutecimiento parece haberse apoderado de las delicadas mentes técnicas para supeditar la estrategia de mercado de los productos a oscuras razones psicóticas y a luminosas ponderaciones dinerarias. Mi consejo es que, cuando se decidan a elegir, utilicen ungüentos de máximo índice de protección solar, a la vez que poderosos escudos anti-GPFs.

RÁPIDAS CONCLUSIONES

De todo lo dicho hasta ahora, yo resaltaría lo siguiente:

• Visual J++ 1.1 supone una importante mejora respecto de la anterior versión 1.0.
• La rapidez, fiabilidad, integración, personalización y ayudas han aumentado considerablemente en la nueva versión.
• Los puentes de uso Java-ActiveX y ActiveX-Java han sido también mejorados y simplificado su uso.

Y por esto se impone la actualización de 1.0 a 1.1. Así de simple. Por supuesto mi consejo es que sustituyan también Visual Basic/Fox por Visual J++. Aunque, tal y como andan las cuitas de integración de Microsoft, en breve un solo producto englobará todos los lenguajes. He dicho todos los lenguajes, pero quería decir: todos los entornos de programación de Microsoft.

Por otra parte también he dicho que:

• Casi nada de JDK 1.1
• Ningún Java Bean en la cazuela.
• Ausencia de JDBC

o que aconseja paciencia a los usuarios que necesiten basarse en tales tecnologías. Claro que si les da igual... ¿por qué no codifican en C++?

[1] Desarrollador es a programador lo que político a incapaz: esto es, a la vez una flagrante adulación y un intento de remedar ciertas incapacidades y connotaciones despectivas (aunque no gratuitas) ya prendidas en el léxico español. Se nos asegura que tal nuevo vocablo se debe a que en inglés se dan a la vez "programmers" y "developers". Pero es que en inglés se dan ciertas cosas que en español se regalan, pues sin duda "programmer" es un "hyponym" de "developer", como "wallnut" lo es de "nut". Resulta, al fin, que la citada figura realmente no existe, pues ni un analista ni un programador son en puridad "desarrolladores", que se traduciría más bien por "analistas-programadores", que a su vez tampoco existen (¿Conocen a algún programador que analice? ¿A algún analista que programe?). Decididamente elijo "programador" como traducción de "developer", "usuario" como la propia de "programador de MS Access", y "animal de bellota" como la del "programador que necesita autodenominarse 'desarrollador' <sic>".

[2] En un muy próximo artículo les hablaré largo y tendido de un proyecto Java de esta magnitud en el que estoy directamente involucrado como Technical Manager: El proyecto JEDI (ya pueden adivinar las dimensiones galácticas, por supuesto).

[3] Los programadores de C++ deben estar riéndose a rabiar con la progresiva adopción por parte del pretendidamente mínimo y elemental lenguaje Java de las características, ya disponibles en C++, que lo habilitan para emprender proyectos ni elementales ni mínimos.

[4] JDBC no significa Java DataBase Connectivity , ni nada parecido. JDBC es una marca registrada. Sin más. No es un acrónimo (lo siento, colegas).